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".
Related
I am creating a web page using html,css and js and I am not following any framework so I have only page (that was the requirement). So I have lot of javascript in my page and I want to move my javascript to another script file. So I have two quesions:
1) What's the best way to do that?
2) Is there any way to call my functions as a property like we can do with node_modules.
var printMsg = require('printModule');
printMsg.print();
or in jquery ($.whatever())
The currently best way to organize your project is through using Webpack. It's allow you to module your js code easily and they a have plugins for almost everything. Take a look at their guide as knowing webpack will make your life easier. Using their guide, It might take you 5-6 hours depend on your dedication.
That's ES6 and knowing webpack will solve like 99% of your problems.
Here's my webpack-simple-template. You can take a look at how I set thing up.
Understanding Laravel Mix
I am currently in the process of migrating one of my websites to Laravel in order to make it a little more maintainable in future... I have plenty of experience building API's with Laravel but I have very limited experience building websites with Laravel and resultantly I am in need of a little bit of guidance from another pro.
In short, I would very much appreciate answers to the following very simple questions if anyone can spare me a couple of mins...
File based JS & CSS instead of App based
I like to write my JS and CSS files in a particular way where each page has their own specific files relevant to the page. For example, about.php might have the following dependencies:
JS:
jquery.js
any_other_third_party_library.js
app.js (global functions)
about.js (page specific functions)
CSS:
some_third_party_library.css
app.css (global styles)
about.css (page specific styles)
On my own framework, the above would be combined and minified into one file for JS and one file for CSS. From what I understand, Laravel Mix does exactly this...
However, as far as I can see, the way to do this would be as follows:
webpack.mix.js:
// About
mix.scripts([
'resources/assets/js/app.js',
'resources/assets/js/about/about.js'
], 'public/js/about/about.js');
Very simply, what I would like to know; is the above the correct way to go about this? Is there a better, more efficient, way to automate this for each page?
What are the bootstrap.js and app.js files?
From what I can see, these files just load dependencies but this is a little confusing as some dependencies might be page specific... Please can someone explain in a little further detail what these files are for? Or at least, what the difference is between them...
Getting rid of Vue
I have no interest in using Vue in my project so I have deleted the following files:
/components/Example.vue
and the Vue code in app.js
Does this matter in any way?
You'll bundle up all your styles and scripts a single file each and serve them to the client minified.
For front end assets, call mix.sass('resources/assets/sass/app.scss'). In that entry point to your styles you will be able to import your other stylesheets as you need using Sass's #import 'about'; syntax. (Rename your other CSS files to end in .scss too).
For your back end assets, call mix.js('resources/assets/js/app.js'). Then, similarly you can import other JavaScript modules using import './about.js';. You may want to look up ES2015 modules so you can learn how to write modular JavaScript.
Read through the bootstrap.js file to see how Laravel hooks up jQuery and Vue by default. You don't need any of this, so remove whatever you don't want or delete the entire file if you don't need any of it.
Vue comes out of the box with Laravel but it's just a suggestion, you can replace it with your own front end framework of choice or rip it out and replace it with nothing. Up to you.
Edit: Long story short; use mix.sass and mix.js, read up on using Sass and ES2015 modules to write awesome code.
I would like to use meteor with a bootstrap admin, i.e. a bundle including several bootstrap plugins, script and everything typically made as a kind of framework for developing a web application.
Usually those bundles comes with a lot of dependencies, such as external links for fonts, IE hacks as well as their own shipped file of bootstrap, jQuery and other stuff. If we were in a regular php-like framework it would have been fine.
But in order to make such a template be "native" on meteor, I thought to refactor it in such a way that local dependencies (script and css basically) are stored into folders and not loaded via a <script src="…"></script> tag (otherwise the local path would not be found) but I doubt it is really the best practice, this is why I do consider 3 options:
To use the project/public folder in order to store all the bundle's dependencies (as if it would have been in php for example)
I might refactor the bundle's code by removing any script or style tag aimed to import the js or css into the page and add the corresponding js file aside so that meteor will dynamically load it during at runtime
Like in option 2 but instead of using the bundle's jQuery source files I would install the official jQuery's package for meteor (if existing).
The first (1) option should be the quickest one to get something running but it would not be very meteor native. The advantage however would be to keep the code near to the original one and being able to upgrade once a new version of the bundle would be released.
The 2 other options would be much more elegant (especially the third one) but it would involve a lot of refactoring and induce the risk of introducing bugs I did not expected.
My preference for now is the first option one but I'm afraid of not seing the drawbacks of this approach. Does someone have any experience in importing manually the CSS and JS files the "old fashion way" in meteor ? What is the risk of such an approach compared to using the "place in folder to include" way of meteor ?
I've developing JavaScript since many years but have never really thought about the whole testing, developing and building stuff - but I realized it's pretty much necessary. We've just used a Subversion repository with simple release tagging (switching to git soon). As a new bigger pure JavaScript project (using jQuery) is arriving soon, I'd like to optimize the whole process.
I already did some research but never found a good starting tutorial.
It's definetly a good idea to split classes and separate code blocks into several js-files and not a big one (as Prototype or jQuery do it). These js-files must be "build" into a single file. How do I achieve that?
It's pretty much necessary to Unit-test the stuff me and my colleagues are coding. I found the js-test-driver which has an eclipse plugin that seems to be doing his job quite good. If my developer-folder contains all these src- and src-test-files, how do I integrate this in the building process?
For testing, take a look at this: https://stackoverflow.com/questions/32809/javascript-unit-testing
For merging all of your JavaScript into one file you can use something like YUI Compressor. You need to be looking for a minimizer first, compression second. A minimizer just takes the files and merges them together and gets rid of whitespace. A compressor will actually try to optimize the js for you by changing variable names and removing unnecessary code.
As for unit testing I am unsure of how you will want to do that. There are a few unit test libraries out there. A popular tool for testing is Selenium. I don't currently do unit testing so I am out of my element there..
For setting up your code you could always look at using a JavaScript framework like ExtJS or JavaScriptMVC. Those help you with setting up your code in the proper way and also helps focus your team on the proper standards and coding structure while also writing a lot of the code for you so you don't have to re-invent the wheel.
EDIT: Just a quick after thought. Even if you don't want to use a JavaScript framework, I would suggest checking them out, especially ExtJS, just to see how they organize their code and some of the tricks they do to keep it clean.
I'll answer part of your question:
These js-files must be "build" into a
single file.
This is possible only with server side language - in ASP.NET you have built in tools for that, otherwise build your own "merger" server side file and reference that file instead of the actual .js files.
These js-files must be "build" into a single file. How do I achieve that?
Definitely keep your files separate in version control, and only merge them during the build process.
The YUI compressor mentioned elsewhere is a java-based tool that will not only merge but -- of course! -- compress your files for faster download.
If you just want a simple merge of files, a simple Perl or bash-script (or other preferred scripting language) could concatenate multiple .js files into one for release -- just make sure that the build script also updates all HTML in the release to reference only the single page.
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.