I have created two separate add ons. One for getting input from the user and storing in simple-storage. In the other one the actual add on function. Both work fine. But when i merge these both main add on code in to a single main code they didn't work. So i wonder whether there can be two js files in "main" add on directory and is communication possible between them?I need one of the js in main directory to be able to access the simple-storage of the other js in the same main directory.
I'm really not sure what your overall goal is, please provide an example for a more specific answer. If you're using the Add-on SDK, only code in main.js will be run, but you can use commonJS modules to implement various features and use require to import them into main.js.
Please see the docs for more information on how the Add-on SDK works:
https://developer.mozilla.org/en-US/Add-ons/SDK
Related
I'm working on a library that lets users run Node processes from inside another application. The library is called "max-api"; functions for sending data to the host application are exposed through a Node module and are loaded in the expected way:
const maxAPI = require("max-api");
However, the user never interacts with this module directly. Rather, when the host application launches the Node process, it intercepts the call to require, checks if the name of the module is "max-api", and provides the module if so.
This works great, the only issue is we have no way to provide type definitions for this modules. So, the user doesn't get any autocomplete or validation for functions in the "max-api" module. I was thinking of writing a VSCode extension to provide these, but I'm not 100% sure how to get started. Thanks in advance for any advice.
You could write a TS typings file (see Definitely Typed). This would be installed in node_modules/#types and vscode will automatically pick it up to provide code completion for your module.
I am trying to use Inferno to render on the server. The documentation inferno-server and server-side-rendering does not say show to set-up babel & run the sever.
All I could find is InfernoJS Babel Plugin but noting about running it on Node.
Any help would be appreciated.
Could you explain what you mean by "Running on node"?
Inferno Babel plugin converts the JSX code into a regular JS code, which runs without problems on node (the server uses renderToString). While you are not using browser elements (document and other tools), everything should be fine.
Then you need to make a separate component for the client, which when requested will be given as a bundle along with the html page, and then using hydrate function to "cling" into webpage and bind items.
you can check my repository (although this is for TypeScript): https://github.com/MrFoxPro/inferno-isomorphic-tempalte
I'm interested in using Hot Module Replacement with a newly created React app.
Facebook Incubator's create-react-app uses Webpack 2 which can be configured to support HMR, however in order to do so, one needs to "eject" the create-react-app project.
As the documentation points out, this is a "one way" operation and cannot be reversed.
If I'm to do this, I want to know what I might be giving up. I've been unable to locate any documentation that explains the potential drawbacks of ejecting.
The current configuration allows your project to get updates from create-react-app core team. Once you eject you no longer get this.
It's kind of like pulling in bootstrap css via CDN as opposed to downloading the source code and injecting it directly into your project.
If you want more control over your webpack, there are ways to configure/customize it without ejecting:
https://www.npmjs.com/package/custom-react-scripts
I'm wondering what the convention to use is when creating a component inside an addon project... If I generate a component in my addon project using ember-cli#0.2.0, the blueprint will create a js file in addon/components, a template in addon/templates/components, and a js file in app/components. The part I'm not real clear about is where templates should live for these components. If my component template requires a partial, I need to put the partial template in the app/templates directory. If it lives in the addon/templates directory, it can't be resolved. So the question is this: Is it best to put all the templates (the component template and the partials) in the app/templates directory or leave the component template in the addon/templates/components directory and the partial in the app/templates directory? The latter feels slightly disorganized and the former seems more correct only because of the behavior of the blueprint. Anyone have any insight?
Thanks in advance.
Ember-cli is under heavy development so a lot of the file structure is likely to change soon, but here on some insights on the current state of the folder structure and why it is arranged the way it is:
The app/ folder is what gets directly imported into your application. Helpers are pulled from here, which is why you have to have a file for each of your components in this folder. Additionally templates will get pulled from the main application here, and as such they will be accessible in the ways that templates are normally accessible in an ember app (render, partial, and standard resolution).
Some people choose to place all of their components code in app/, but this is a bad idea because the addon/ folder exists not only as a separation of your addons code, but as a way for it to be imported using ES6 imports. So, while you can't directly access the components under addon/components/, you can import them into your application like so:
import SomeComponent from 'some-addon/components/some-component'
This is very useful for addon consumers if they want to extend an addon to add some functionality.
Templates in addon get precompiled in the build tree, which makes addons a bit more robust (for instance if they are using a different version of htmlbars they will still be compatible with the base app). However, they are not accessible via the resolver, so you have to import them manually in your addon's components, which is why the blueprint for addon components looks like the following:
import Ember from 'ember';
import layout from '../templates/components/some-component';
export default Ember.Component.extend({
layout: layout
});
Styles for addons can either be placed in addon/styles/ or app/styles/. In addon/styles/ they are also precompiled and included in the application by default. I highly recommend including styles in app/styles because this makes them accessible using preprocessor imports in the base application:
#import some-addon/main.css
This makes them completely optional to users of the addon, without resorting to app.import and config trickery (which is good because nested addons _do not support app.import. Don't use it.)
NOTE: They are not automatically namespaced, so you should put your styles in a folder to make sure they aren't conflicting with other addons styles.
In summary:
Any addon code that does not need to be directly accessible by the base app via helpers, initializers, etc. Should live in addon/
Anything you want to be accessible by ES6 imports should live in addon/
Templates should live in addon/templates/ and be imported manually
Component stubs, initializers, and other files that should be included in the standard Ember build chain should live in app/
Styles should live in app/styles/ and should be namespaced in a folder (e.g. app/styles/some-addon/)
Don't use app.import.
anybody knows how to check if a js/css file is already included with typoscript?
Example
[Template_A.ts]
page.includeJS {
jsfile = fileadmin/Template/js/jquery-1.10.2.min.js
}
now if i got an extension with the same include e.g.
[Extension_A.ts]
page.includeJS {
jsfile = fileadmin/Template/js/jquery-1.10.2.min.js
}
Is there a way to prevent this kind of double code injection? Maybe i got another Template e.g. Template_B.ts where jquery is not included - than the Extension_A.ts has to include jquery by itself.
Kinldy
You can use the same key inside includeJS such it just gets overridden if you include the file twice.
Other than that you should put jQuery into includeJSlibs, such that it is loaded before the other JS files.
Other than that, the TS should be unique for each page. Therefore you always to make sure anyway that all resources are included in-order.
You should not include JS libs with the automatic extension TS setups. Use your documentation to tell the integrator what needs to be included and what not.
The various and independent inclusion of scripts by plugins and templates is one of the tricky points in TYPO3. As far as I know, this point cannot be managed at one single point.
There is a plugin "t3jquery" that offers to build, compress and share a common jQuery library. It also has a service to analyze other plugins for their dependencies. But this doesn't solve the problem in general, as many plugins don't check for libraries already loaded.
The most stable way is to remove all plugin's references to libraries manually in your TypoSkript. This gives you some simple additional TypoSkript lines. I use lines like these:
plugin.tx_imagecycle_pi1.file.jQueryLibrary >
plugin.tx_imagecycle_pi1.jQueryLibrary >
plugin.tx_multicontent_pi1.file.jQueryLibrary >
plugin.tx_multicontent_pi1.jQueryLibrary >
# Fluid
page.headerData.998 >
You can find the matching TypoSkript descriptors by searching for the library name in the TypoSkript browser or by greping in the plugin's source code. You will also need this if you wish to add libraries as part of content that was get by AJAX, thus separating the libs from the page content.
Here's a tut (in German): http://jweiland.net/typo3/typoscript/javascript-manuell-entfernen-oder-einbinden.html
Futher possibilities you can check:
Some plugins are written in good structure and offer to keep back their Javascript in the settings.
Some script inclusions may come rather from the static template but from a plugin, so don't forget to have a look there.