Me and my team are making a React website. We've done all the coding bits, however, I'm worried that with more people joining in, our code-base can become messy, as in:
Improper indentation used (preferred 2 space in .js files)
Extremely long lines (I'd prefer to set a limit for number of lines in a row)
Incorrect location of CSS files: For e.g. storing .css files under components (I'd prefer them to be in src/ but outside src/components/)
No Warnings when running npm start.
From the little I've tested out testing libraries for React, they mostly deal with code errors. I'm aware in Android it is possible to keep checks for first two options using testing libraries. What are React/NodeJS solutions for the same?
You can use Prettier to format you code with just one command in editors like Visual Studio code.
Incorrect location of CSS files: For e.g. storing .css files under components (I'd prefer them to be in src/ but outside src/components/)
There is no way to automate this as far as I know, but this should be possible by setting the right example first and communicating your preference.
Related
When I run npm run build a build directory is created with js chunks. I have noticed that there is a [number].[hash].chunk.js file that is not listed as one of the entrypoints in the asset-manifest.json file.
Instead, this file appears to be referenced in the runtime-main.[hash].js file.
What is the purpose of this file? I have noticed that in it's map file it references web-vitals.js. Do I need to make sure that my application will be able to access this file? Is it critical to the application's performance?
This is a react app was created with typescript using npx create-react-app my-app --template typescript
At build time your bundler (webpack) will determine what code is necessary for the main entry bundle and which code can be loaded later (aka. lazy loading). It will also determine which files are shared by different entry points and will bundle them as a shared asset. This allows your application to load quicker on initial load - only loading the resources it needs when they're needed.
There are complex algorithms which determine how to split code in a way which is beneficial to both end users and your server/network. In general, don't try to analyze it. You can trust that the people writing the algorithms are smart and striving for the greater good, and it's always getting better.
NOTE: I used to work for a company that built a bundler and implemented code splitting long before webpack, rollup, and friends came along. The bundler was used for years for the likes of Sam's Club, Levi's, and some fruit company. It did not take long for webpack and rollup to surpass the one we had built, but I still have a pretty intimate understanding of how it all works, and the guys who built it were some of the smartest people I've ever met. You don't really need to understand the output files - I highly doubt there are any unnecessary files being generated.
I have had a developer create a website or app in React. This is already on a webserver and does what it should do. Now I want to develop the frontend myself, which would be no problem if I knew how to edit the code.
On the server I have an index.html, some stuff like favicon and a folder. This folder contains the folders "css", "js" & "media" and I don't understand their content. In the folder "css" are for example the files "main.12345.chunk.css" and "main.12345.chunk.css.map" Both look very cryptic.
Now I found out after some research that this is probably a compressed representation. Possibly compressed with Webpack?
But how can I edit these files in a meaningful way and understand what was coded there in the first place? Normally I would just download the file to be changed with Filezilla and edit it with an editor or Visual Studio code, but in this case I have no idea.
Those "cryptic" files are probably minified. Minification is a process where the original code is minified using several approaches, making it much smaller in size and also sometimes better performing. This is done by Webpack with a build process.
Those files are not meant to be develop with (or even read for that matter). Their sole purpose is to be optimized and be run in a production environment. It's very hard or even impossible to understand those, you would basically have to reverse-engineer them to understand what's going on. Many websites actually use minification for this additional bonus of protection of their application logic, because minimization basically obfuscates client side code. For example, the WhatsApp web client written in React is heavily obfuscated, in order to not allow anyone to write a WhatsApp client (there are efforts for this particular example, but it takes lots of time).
TL;DR: You have to get the original source files in order to edit them.
But how can I edit these files in a meaningful way and understand what was coded there in the first place?
They really are not designed for editing.
Edit the original source code to the application, then run its build script and deploy the output from it.
I am working on an AngularJS app.
According to a lot of articles in the Web, every file on the project can not have more than 100 / 150 lines of code.
Then, here is where my concern comes up: if I am concatenating/minifying my code, at the end all of the code will be in one very big single file.
So in that case, the rule(good practice) of the 100 / 150 lines of code still applies in this case ?
Kylek is right on about small files being for developers, and big files being for machines. More specifically, if you're interested, read about synchronous http calls and web loading speed. Basically, every separate external resource you have load on the page (a css file, or a javascript file) requires overhead on top of the actual content download, so for maximum speed, you want both a small number of files (accomplished by concatenation) and a small content size (accomplished by minification).
Of course, as a developer, you still don't want to have to worry about this while writing and maintaining code. Check out grunt, specifically uglify and cssmin, which can keep monolithic minified files up to date for you while you work on your source. Regarding angularjs in particular, make sure you're using dependency annotation or minification will break your code.
Keep files small is not a performance good practice but a way to keep things organized for developers and to find quickly what you are looking for, it's not for machines but for humans.
No human will have to develop minified files, so no coding rules apply to minified files. A contrario, minify and concat JS, CSS etc. make your pages load faster. It's a performance good practice.
By the way, do not follow a rule because some one tell you to. Be sure the rule match your case, your project, your team, etc.
I am using backbone.js in a legacy app to rewrite separate pages into individual bits of backbone work.
I am not using any routing and it is not a total single page application.
Only certain pages are individual backbone.js applicaitons.
At the moment I have all my backbone javasript in one file for each page that uses it which is painful to work on.
Would it be wise to use something like requirejs on a page by page basis or is there something better I could do in order to split the page up in development and serve one page in production?
That depends largely on what your existing codebase looks like.
RequireJS is a great tool...if your existing code is set up to support it, or you have a small enough codebase to be able to convert it without breaking everything. However, not all legacy JS code is, especially if it's part of a larger system (I personally ran into this problem with a Backbone project I'm working on). If you can, then by all means, make use of it. The big advantage, as far as I know, with RequireJS is that it doesn't actually fetch and load the Javascript files until you need them. So you can have one RequireJS call that's in all of your pages, and only download what you need, when you need it.
There are other ways, however, to combine your Javascript code at production time, which, again, depends greatly on your setup. Many content management systems include "minify" scripts that handle it automatically for all of your Javascript files. You can also do it "by hand" with Minify, YUI Compressor, or one of the many other minification tools out there. (You can also do it "really by hand", and develop in multiple files and combine them via copy+paste, but that's really more work than is necessary.)
Regardless of how you go about doing it, I highly recommend breaking your projects into multiple files (not only into a file for different projects, but multiple files within the projects, to hold each view and models if they have significant code). It makes it infinitely easier to maintain.
I would like to know your opinion about how you would organize the files/directores in a big web application using MVC (backbone for example).
I would make the following ( * ). Please tell me your opinion.
( * )
js
js/models/myModel.js
js/collections/myCollection.js
js/views/myView.js
spec/model/myModel.spec.js
spec/collections/myCollection.spec.js
spec/views/myView.spec.js
This is how I've traditionally organized my files. However, I've found that with larger applications it really becomes a pain to keep everything organized, named uniquely, etc. A 'new' way that I've been going about it is organizing my files by feature rather than type. So, for example:
js/feature1/someView.js
js/feature1/someController.js
js/feature1/someTemplate.html
js/feature1/someModel.js
But, oftentimes there are global "things" that you need, like the "user" or a collection of locations that the user has built. So:
js/application/model/user.js
js/application/collection/location.js
This pattern was suggested to me because then you can work on feature sets, package and deploy them using requirejs with relatively little effort. It also reduces the possibility of dependencies occurring between feature sets, so if you want to remove a feature or update it with brand new code, you can just replace a folder of 'stuff' rather than hunting for every file. Also, in IDE's, it just makes the files you're working on easier to find.
My two cents.
Edit: What about the spec files?
A few thoughts - you'll just have to pick the one that seems most natural to you I think.
You could follow the same 'feature folder' pattern with the spec files. The upside being that all of the specs are in one place. The downside is that now, much like what you're currently doing, you have to places for one feature's files.
You could put the specs in a 'spec' folder of the feature folder. The upside is that you now have actual packages that can be wrapped up in a single zip file with no chance of clobbering other work. It's also easier to find directly related files for writing tests - they're all in the same parent folder. The downside is that now your production code and test code is in the same folder, publishing it (possibly) to the world. Granted you'll probably end up compiling the production javascript down to one file at some point.. so I'm not sure that's much of an issue.
My suggestion - if this is a large application and you figure you're going to have a few hands touching the files, leave something like a 'package.json/yml/xml' file in the folder. In there, list out the production, spec, and any data files you need for testing (you can most likely write a quick shell script to do this for you). Then write out a quick script to look through your source folder for 'package.whateverYouChose' files, get the test files and then build your unit testing page with it. So, let's say you add another package.. run 'updateSpecRunner' or whatever you name the script, and it'll generate you another SpecRunner.html file (or whatever you named the file your running the specs on). Then you can manually test it in a browser, or automate it using phantomjs/rhino.
Does that make sense?
You can find a good example how to organize your application to this link
Backbone Jasmine examples
It looks more or less like your implementation.