Split files, borrow parts

All the code you have written so far fitted in one file. Real apps do not work that way. Write hundreds or thousands of lines into a single file and time melts away just finding the place you wanted.

This chapter teaches you how to split code into files by what each one does, and how to bring in parts other people have written.

The tools for splitting are export and import. In one file you mark something "outside may use this" with export, and in the using file you import it and call it. What you have not marked cannot be seen from outside. Think of it as the same idea as a function's scope, working at the level of files.

What matters is how you split. Raising the number of files has no value in itself. Cut by job — "the file that only calculates", "the file that only displays". Then, when you go looking for the place to fix, you can guess: "this is about calculation, so it is that file." Cut vaguely by line count, on the other hand, and you only get more files where you cannot tell what is where.

The other theme is packages. There are a great many "common jobs" out in the world — date arithmetic, tidying data — that someone has written and published. Pull one in and you need not write it yourself. Even in professional development, most of an app's code is made of borrowed parts.

Take in what you should think about when borrowing, too. Putting someone else's code into your app means taking on that code's faults along with it. So it is not a case of the more the better. There is no need to borrow something you could write in a few lines; conversely, for work that is complicated and easy to get wrong, borrowing something widely used is often safer.

In this course you get the experience of pulling packages in through mock parts prepared inside the material. The actual installing (typing npm) waits until you move to developing on your own machine, but the feel of bringing something in with import and using it you can get here.

Two ways of writing export come up: sending several out with names, and sending out just one representative for the file. Which you use changes how the import is written. It is confusing at first, but choose by whether that file offers one thing or several.

The easy thing to stumble on is writing the paths. ./ is the same place, ../ is one up. When everything suddenly fails to load after you tidy the folders, this is usually why. When an error says it cannot find such a file, suspect the path first.

Splitting files is one of those things you only appreciate once the code has got long. For now it is enough to know "there is a way of doing that". When you start building an app of your own, you will certainly be coming back to this chapter.

This course lets you actually make several files and have them load each other. Add a file, export from it, import it from another and run it. Move your hands and you will find it is simpler than you think.

For that moment, there is one thing to take away. You split things so that you can find them later. Neither fewer files nor more files has value. The question is whether you in three days, wondering "where was that work again?", can get there without hesitating. When the call is close, decide on that.