Define your code once and reuse it with Scripts
Now that you have a good grasp on the whole architecture and understand how data flows from one place to another, let's talk about scripts. And no, we are not talking about the SFCC Digital Scripts API this time.
Now we are going to talk about the scripts folder you have inside your cartridge.
Avoid putting too much logic in Controllers
Take a look at the Cart Controller:
As you may notice this Controller does only have defined enpoints and no other helper functions are defined there. But you may think that this could be because each of this enpoints is huge and contains a lot of lines of code, but it's not the case. Base controllers, at least, make use of helper functions defined in external scripts.
Doing things like that the code can be reusable in other parts of your application and if any detail has to be changed in your code, it has to be changed and tested in all places where you created a copy of it.
Your Functions Should Do One Thing
You probably already heard this before. There is a lot of debate around this topic that functions should do only one thing but nobody defines what is the scope of this one thing.
If adding a product to cart is one thing, but it requires me to write 100 lines of code to do all the validations, retrieves data necessary and so on to get there, should all of these different things that are needed to add a product to the cart be inside my function?
Robert C. Martin introduced the Single-responsibility principle term. The definition you can find everywhere and you should take in mind while programming is: The single-responsibility principle (SRP) is a computer-programming principle that states that every module, class or function in a computer program should have responsibility over a single part of that program's functionality, and it should encapsulate that part. All of that module, class or function's services should be narrowly aligned with that responsibility.
What are Scripts
To avoid replicating a piece of code in all places that need it or adding an excess of logic in just one place, we can isolate these pieces of logic and save them inside the scripts folder to be called from anywhere, backend and frontend.
It makes maintenance much easier, makes it easier to read functions and reduces drastically the chances of breaking something because you did not know that a certain script that you changed was replicated somewhere else.
Below is how the scripts folder is currently structured, but as improvements are made in the repository it might look a bit different when you are reading this page.
We won't go into much detail on what each script does, but if you keep in mind what we just discussed about one function should do one thing, using good judgment, you should have no problems using scripts and also adding your own functions there whenever needed.
As good examples on how to start thinking this way have a look at the following files and check on how many places functions inside these helpers scripts are being called: