What I've learned

• Projects such as this one that use third-party APIs like Spotify's Web API break the CI/CD deployment preview. Why? Because once I push to a feature branch, and then create a pull request, the CI kicks in. If it builds correctly, it provide a temporary URL where the integration of the PR was deployed, and this is the problem : this temporary URL must be manually be entered every time in the Spotify developer console to authorize it to use their API, and it takes NO regex for all prefixed domains (or anything like that)!!!!
• Not using libraries like redux and redux-sagas for medium to large scale project is the same as shooting one's self in the foot
  • By trying to implement these myself, i've learned that they are not that complicated, but they have the advantage of being thorougly tested, so once less immense thing not to worry about. Being able to rely on the open-source community for this is one of the many foundational stones for a successful project.
• Use Redux Toolkit to avoid all the plain redux boilerplate code. This has the advantage to still include the flux architecture, the stability of redux, while being able to be more flexible with regards to code maintenance and scalabilility. In addition, it automagically configures the redux devtools Chrome extension, which is an incredible tool.
• Use NextJs instead of Create React App to bootstrap the project. Why ?
  1. because of the isomorphic Javascript capabilities it brings, meaning that they have propbably written a custom webpack loader to be able to import any ES5 module available on NPM using the ES6 import syntax, which really boosts the JS code sharing (isomorphism) between the frontend and the backend code! Tried to do this myself with netlify-lambda, and while it makes it easy to write the netlify backend/ serverless/JAMstack functions in ES6 (using babel transpiling in the background), you are on your own as far as importing ES5 modules into your backend ES6 code. There was a solution, a package, called 'script-loader' which allowed for a special import syntax, ie import 'script-loader!../../lib/rtree';, but it as been discontinued and archived. It points towards webpack documentation to write your own script loader. But, since my project is bootstrapped with Create-React-App (CRA), unless I eject, which is not recommended, I cannot tap into the underlying CRA webpack configuration; and frankly, Webpack is NOT something I wanna get down and dirty with! I would love too, and I took several mini courses to understand it passed the high level stuff, but I still don't have the know-how to pretend I'm going to eject from CRA, write my own webpack loaders, and then configure CRA webpack file, which spans thousands of lines of code! Configuration is not my cup of tea, whereas focusing on new features for my apps is a passion. Note: there are solutions to rewire CRA without ejecting but this is way too hacky for my taste)
  2. the ease to create new pages without having to configure any router. This tool grows along with the complexity of the project : it can be anywhere from simple to full-blown applications. Very versatile tool.
• Well defined and stable specs are another foundational stone for a succesfull project outcome.
• Implement the Private Route pattern using the react-router-dom
• Feature-centered directory structure 👍, like it is right now, but for greater coder’s convenience, I would include the redux-related files into the corresponding feature directory. Right now, they do sit in their own feature directory, but are all sitting inside a redux directory, at root level.
• Test-Driven Development is something I keep on putting to the side, although I periodically dive into the subject, for one day I will adopt the technique, I swear ;)