I am very new to Firebase (just learning the ropes). It seems to be very simple to pick up, but I have only one question that I know can be answered here.
In all of the basic tutorials, that is, where their web app is only one page, they have only one file (app.js) to reference for information.
My question is this: Does every single page within a web project reference this one JavaScript file? As in does index.html call app.js as well as page1.html, page2.html, and so on?
It seems like this file could be heavily loaded with tasks if it is apart of any complex application. Is there a better way to do this? Thanks!
If you are using Angular, tutorials such as the one below suggest that you would have a .js file for each view.
Read more here: https://code.tutsplus.com/tutorials/creating-a-web-app-from-scratch-using-angularjs-and-firebase--cms-22391
What I found is that there is no real answer for this question. It varies based on the complexity of the project. For my particular case, I decided to keep larger functions and operations within the app.js file, and simply call them from smaller .js files. This allowed me to keep everything organized and efficient.
Related
i'm starting to develop an app using Laravel, Vuejs, and blade for template engine.
Firstly, i'm new in Vuejs's world, and maybe is a simple task, but i didn't find an answer in any discussion.
The core idea is to use .blade page, and, when i need vuejs components, add them in the page passing server's data with props array. Everything's working fine, but after playing around for a bit, i've noticed one probably furure problem.
In the laravel's documentation, we register the component, or whatever Vue setting in app.js: then, using laravel mix, we boundle in a single file all the code(e.g imports, requires, different js pages...), and finally we load "app.[hash].js" in our page with a script tag. I've noticed that even only using a few vue components, app.js growing very fast(of course, we import every components in one file), even dinamically importing components and not setting them globally.
My question is: is normal to boundle all js code in a single file(having a large file), or is there a way to import vue component only when they are added in the .blade files, maybe with some sort of webpack(laravel mix) setting?
Thanks in advance for any support.
Found the solution after post the question:
Marcin and GoogleMac's answer might be both right, but i found an interesting topic about that, and i 'd want to share for anyone could have my problem. I suggest to check out this link https://alexjoverm.github.io/2017/07/16/Lazy-load-in-Vue-using-Webpack-s-code-splitting/, where they talk about code splitting.
I think this could be the best approach, mostly because even in vue's documentation talks about(detail here https://v2.vuejs.org/v2/guide/components.html#Async-Components).
My bad for haven't checked in detail documentations.
It's good to bundle js code in a single file because it's going to be downloaded only one time by the browser and cached.
JavaScript code is not that that big so don't bother yourself with it.
I agree with Marcin's answer, but if you are wanting a workaround, comment out Laravel's built in Vue registration in app.js and just use a cdn in your blade files.
You may add multiple app.js (including multiple router, vuex if needed).
Entry them separately on webpack.mix.js.
And then include suitable app.js file as needed in the blade file.
It's much easier I think if you don't want share some .js code with any user who will not use those component ever.
NB: Of course lazy loading is a solution, but that this is more convenient solution to me as I'll not deliver any component to the user who don't need it.
How to organize Vue-JS project [files and directory]: Non Javascript way?
Coming from a non-javascript background, I found Vue.js very intuitive and easy to use. My earlier experience in Javascript is with JQuery and vanilla javascript on the browser.
I created an application using Vue , Vue-components and vue router. Everything works fine.
My problem is, I have ended up writing a lot of code in a single index.html file of my project. This file contains over 10 templates that I have created and attached to different component in my app. I want to know that is there a non-javascript way to organize these templates in seperate files.
I see that there are options using webpack and browserify to modularize the project. But coming from non javascript background, I don't find them intuitive. I don't want to go node - npm way because that has its own learning curve and moreover it downloads a dozen of files and dependencies in my project which I don't understand. I am old school and more comfortable downloading the files and including them in the webpages.
So probably, you understand where I am going to. I need a solution where I could put my templates as separate files and read those files in the different components.
What I have tried :
Declaring the templates inside my components. But writing all that html inside the component is not that clean. It also, makes my JS file too huge. I am better in putting all data in the index.html instead.
Storing template as smaller chunk "homepage.html","about.html" and in my components, using $.get / $.load to read different components in ready function of the component. This works but I still have to fire an additional ajax call for each component which is not efficient.
Please refrain from suggesting the obvious node-npm [webpack and browserify] way. I know thats what is supported by Vue but this needs a learning curve and complete setup. Answer to this question would actually help other developers who hesitate going the node-npm way.
Please shout back if you need more clarifications to the question.
The options you've mentioned are your only real ones... the HTML of the template needs to be available when it's needed, so you either have to have it within your html file off the bat, or load it using AJAX or an in-browser loader like RequireJS (and this extension that allows it to load HTML https://github.com/requirejs/text).
In-file templates make sense for very small projects. As your project grows, you'll need to start using the tools that are built for this. NPM rocks and every JS package that you'll ever need can be included in your project in seconds.
I highly encourage you to try the Vue CLI
It does use node, npm, webpack and downloads dozens of files. Which you've you've explicitly asked for not to use, so let me clarify:
The Vue CLI takes care of the complexity and configures webpack for you.
You don't even have to know it's using webpack.
It's very developer friendly (it even has a built-in gui) and lowers the barrier to entry compared configuring a webpack config.
I hope you'll also find it "intuitive and easy to use".
I am primarily a c# programmer. I have recently been getting into some jquery development. when I am working on applications in c#, I create a new class file (.cs) for every new class that I create.
How do people generally structure their jquery/javascript applications. I would like to reuse some functionality across pages, so do I put each function in it's own .js file? or is it best practice to group like functions into files? I can't see putting each on in it's own file as that would create many calls to import individual file into a page....
How are other people handling these types of situations.
Thanks for any thoughts.
EDIT - I should have mentioned that I am beginning to look at unit testing with QUnit and figured it would be good to have proper structure of my project to better facilitate unit testing.
If you DO put them all in separate files, you would want to have a build script that combines and minimizes them into a single one (or just a few) so you do not have 500 Javascript files to download to your browser.
I would suggest putting your common functionalities to a util.js file and then arrange your javascript codes according to functionality.
However it is not a good practice to have lots of js files included in every page, thus you might consider combinin the files into a single file and minifying that final js file. this way you would have optimized your final product while being able to unit test functionalities separately.
I generally keep all plugins into their perspective files but functions I create I tend to place into a "global.js" file that the entire site will pull from. Then I don't have to worry about pulling in specific files when a need a specific function. It will all be in the global.
Put it all in one file. Multiple HTTP requests are more expensive than big files, plus you're assured that the file containing the function you need is already loaded.
I'm pretty new to Sencha Touch and am trying to make a simple application that has a login form and makes calls and fetch results into lists.
My question is, how should I create the structure of the application? Should it all be inside one .html file? or should I different pages for each list and the login page? If so, how can I change views from one page to another and get transition effects?
There is actually a generator which you can use to generate the canonical app structure. From the Sencha download, go to the jsbuilder directory, then run a command similar to this:
./sencha.sh generate app MyApp path/to/myapp
Also, this slide set demonstrates the structure, though you may have to dig for more of the philosophy for why things are where:
http://www.sencha.com/conference/sessions/session.php?sid=322
And here's the example app talked about in the discussion:
http://cl.ly/1d1S282O1Y2c3N1v1j1i
It's fine to use a single HTML file to get things started, but in the long run it's worth making the application structure consistent with 'best practices' so that others can look at, and understand, your code subsequently.
Sencha Touch generators (coming in v1.1) place the launch logic in a file called app.js and then have files for each model, view and controller (in respective directories).
While you may not be building a fully fledged MVC application from the start, you should probably still use these conventions. Take a look at the Twitter and Kiva apps in the SDK (and at http://dev.sencha.com/deploy/touch/examples/ ) foor good examples.
The index.html file can link to each file individually, but of course for production, you are also advised to look at the JSBuilder tool to package and minify them all so that the device can fetch them in one single HTTP request.
I would break it up by major function (i.e. purpose). For mobile apps, you want to avoid having unnecessary postbacks / loading multiple pages and views if you can help it.
If your mobile app has one purpose, I would keep it on one html page and only break up the JavaScript files as you need to keep it organized.
If it has two purposes (e.g. 1-to ENTER a bunch of information, and 2-to display reports on your data), then I would break it up into two html files.
For example, if you have a mobile app that takes you through a series of wizard steps to perform data entry (i.e. single purpose), I would house that whole wizard inside of an Ext.Panel (on a single page), and swap out each content Ext.Panel "step" of the wizard as the user progresses through the wizard.
Start with the simplest thing and refactor later. I've just done an app in Sencha Touch and it gets quite bewildering looking at the example files. I found the easiest way to learn was to create a single html file and as soon as something became unwieldy or obviously needed a refactor I started creating subsequent files.
I've just started developing an ExtJS application that I plan to support with a very lightweight JSON PHP service. Other than that, it will be standalone. My question is, what is the best way to organize the files and classes that will inevitably come into existence? Anyone have any experience with large ExtJS projects (several thousand lines).
I would start here http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/
This site gives a good introductory overview of how to structure your application.
We are currently using these ideas in two of our ASP.NET MVC / ExtJS applications.
While developing your application your file and folder structure shouldn't really matter as you're probably going to want to minimize the release code and stick it in a single JS file when you're done. An automated handler or build script is probably going to be the best bet for this (see http://extjs.com/forum/showthread.php?t=44158).
That said, I've read somewhere on the ExtJS forums that a single file per class is advisable, and I can attest to that from my own experience.
I suggest users are willing to wait for an application to load, so we typically load all of JS during initial app startup. I suggest loading and eval'ing JS files as needed is unnecessary - especially when all JS will be minified before deployment to production.
I suggest namepsaces, one class per file, and a well-defined and well-documented class hierarchy.
When starting new big project, I decided to make it modular. Usually, in big projects not all modules are used by a particular user, so I load them on demand. F.e., if a project would have 50+ modules, the big probability is that user is working only with 10-.
Such architecture lets you to have the initial code relatively small.
Modules are stored on the server and loaded by AJAX call, eval'uating the responseText in AJAX callback. The only issue with this, you must keep track on module dependencies, which could be stored inside modules as well. I have a class called Module, and I check every new module instance for existance within the task. If it doesn't yet exist, I load it from the server.