I am trying to create production build through the command "sencha app build production"(sencha 5.1.3). It gets created but some of the view is not being served.can some one suggest that how I should ensure all the required js file has been loaded so that the minified app.js should serve fine. Or there are some other steps to create the production build.(I am using sencha 5.1.3)
In order to have all files included you have have to reference them somewhere with one of the config requires, uses, controllers, stores, views, etc.
Sencha cmd determines also the order of inclusion with these configurations.
Related
The build version is working perfectly but can't see where it stores the environment variables. Are they hidden or visible to everyone ?
The Create React App (Webpack) build process "folds" the environment variables into constants in the source, and things are bundled as per usual after that.
They're visible to anyone who looks at your app's script files in their browser's View Source or Inspector views.
I understand that in react you cannot import files outside src folder.
But what is the reason for it exactly and can I disable it?
In my project react web app is only part of the whole thing, and different parts share some files (configs, build output), so folder structure looks like this
ProjectRoot/
config
build-output/
Part1/
Part2/
WebApp/
src/
...
Sure, you can copy files or create symlinks, but that's duplication and inconvenient.
This is a restriction of Create React App only.
This tool exists to get new users up and running with the react framework as fast as possible by abstracting away the tooling. The part of tooling that is limiting you in this instance is their webpack configuration, which is preset to only look for javascript files in your src directory.
That explains the why? but to answer the other half of your question:
how can I disable it?
Is that you would need to eject from Create React App and then modify your webpack config to allow it to search directories other than src/
First - this has nothing to do with react itself.
If you refer to importing javascript modules (for now using module loaders like systemjs, require, etc.) then the answer is:
It depends what directory is being served by web server. If you have set up your web server to serve WebApp/src folder only - then no, browser will not be able to get access to the files outside and so module loaders. If you will serve all ProjectRoot directory - then yes, you can.
If you prepare your web application for deployment using some sort of bundlers (webpack, browserify) - it depends on how you will configure them and instruct to include the required files in the resulting bundle.
I have a problem with a MEAN.js app in that its really slow to load and from the inspect i can see that its loading js in 70 different files.
Couple of questions
Why is there so many js files seperate? Can they not be merged into one and served quicker like YSlow advises?
Edit
'modules/*/client/*.js',
'modules/*/client/**/*.js'
Folder Structure
modules/savings/client/controllers/client.controller.js
MEAN.js has that particular aspect covered. In fact, if you run your app using just grunt command, the app will start running in development environment, and so the js files (either the ones from 3rd party libraries or even your custom js files) are not concatenated nor minified. This helps you while debugging. However this is clearly not good for an app in production in terms of performance.
If you use the command grunt prod your app will start running in production mode and so your custom js files will be concatenated and mninified. 3rd party library files won't be concatenated but grunt will use the minified version of them.
You can see which assets will be loaded for both development and production modes in config/assets/development.js and config/assets/production.js, respectively.
Also if you want to see what are the differences between both grunt and grunt prod tasks you can check your gruntfile.js.
Note 1: The commands I mentioned about grunt can also be used with gulp, since MEAN.js has both a gruntfile.js and a gulpfile.js defined.
Note 2: If, by the time you use grunt prod and still have so many files being loaded, that means you are using an high number of 3rd party libraries and a possible solution for that case is to concatenate 3rd party library files into a vendor.js file however in doing that you might run into trouble, such as some libraries like AngularJS needing the files to be loaded with a specific order. You will need extra caution if you edit your gruntfile to implement such task.
We have an app that was not initially created with Sencha Cmd.
While we will eventually restructure the app to adhere to the structure that works best with Sencha Cmd, for now we just need to know the steps to deploy the app to production in our case.
1) For example, I've heard we need to minify the code by building with Sencha Cmd. Can we do that even if our app was not initially created using Sencha Cmd?
2) I've also heard that we can use Sencha Cmd to ensure that the minified file only contains the classes that are actually used by our application (even reducing the number of ExtJS core classes included). Is that true and if so, can we do that even if our app was not initially created using Sencha Cmd?
3) Anything else to deploy our app to production, especially considering our app was not initially created using Sencha Cmd?
Thanks much in advance!
1) We can deploy & compile our application , even if we have not created the project using sencha CMD. We have to follow the standard application structure given in their tutorial/docs
2)Yes by compiling our js files using sencha compiler/sencha cmd minifies our code to a single file say xyz.js file, so in webapps folder only one file is needed not all other js files containing src code also the import statement in some parent jsp files need to be updated accordingly, instead importing "app.js" . By this process the performance is upgraded as only required/used components are complied.
Note : While compiling our src files,If any component say button,grid etc in any file is used without mentioning its xtype in 'requires[]' field in that particular view file then errors are thrown which are very difficult to track, So make sure all requires[] are updated.
I have a mobile application crated using sencha touch. The app skeleton was generated by sencha app generate. So it contains app.json, app.js etc files and folders. But as I have a lot of extra js files I used a .jsb3 file to build the project. So right now I build it by
sencha build -p /path/to/project.jsb3 -d target/folder/
Now I want to make this build system latest Sencha Cmd 4.0 compatible. How do I do it?
As Lorenz Meyer points out, you can try to use the "requires" keyword on the relevant classes to include your extra JS code. This assumes the JS files you're talking about adhere to the Sencha class system.
Additionally, Sencha Touch's app.json file has a "js" array you could use - this array loads arbitrary JS resources, even ones which don't adhere to Sencha's class system.
You could also use Sencha Cmd to manually compile the additional resources... but that's an advanced topic and would require detailed knowledge of your code to really offer advice.
If all else fails you can just include these JS files in your index.html, loading them from the /resources/ folder (which gets automatically copied into your build output).
At the end of the day, there's no specific migration path for your case - but the above methods are generally the ways to go.
Another point to think about is that each file should contain one class defined by 'Ext.define' and whose name corresponds to the file path ( e.g. The file in /app/view/Main.js should contain the class AppName.view.Main.
I don't know if this is a prerequisite for using Sencha cmd 4.0 or if it is only recommended.
You should not include the javascript files manually in your HTML, as long as they contain ExtJs code and not plain javascript or third-party scripts. Sencha cmd also compresses the files using YUI compressor and builds the theme css in such a way that it only contains required code.