testcontainers is great. I struggled a bit with testcontainers due to the nature of one container per test which just felt too slow for writing gray/blackbox tests. The startup time for postgres was > 10 seconds. After a bit of experimenting, I am now quite happy with my configuration which allows me to have a snappy, almost instant testing experience.
My current setup:
- generate a new psql testcontainer _or_ reuse an existing one by using a fixed name for the container
- connect to the psql container with no database selected
- create a new database using a random database name
- connect to the randomly generated database
- initialize the project's tables
- run a test
- drop the database
- keep the testcontainer up and running and reuse with next test
If your table setup process starts to get slow like ours, checkout psql TEMPLATE (https://www.postgresql.org/docs/current/manage-ag-templatedb...). Do the setup once to a db with known name, then use it as the template when creating the db for each test.
UseMemo should not be used for fetching/kicking off a fetch either. UseMemo fans should be pure. Using logic that belongs into useEffect (logic that happens _outside_ the reactive flow) could potentially lead to other side effects which are very hard to debug. Just a example: a lot of fetch implementations are using fetch with a cache triggered in useMemo returning immediately. You will probably have a setState somewhere in the flow which will terribly interrupt react and break your page.
In case you trigger a native fetch, you've got no way to cancel the call due to the missing cleanup fn.
> UseMemo should not be used for fetching/kicking off a fetch either
Wrong. That's just like, your opinion.
The best time to kick off external calls is during first render, not after the component is mounted and React has gotten around to calling your useEffect callback.
useMemo can be a part of the solution along with useRef and useEffect cleanup(remember it's essentially to the unmount lifecycle hook as well).
A dirty rear derailleur of course also reduces the drive train's efficiency by a lot - which can be solved by cleaning the chain every other month.
When moving towards belt drives, you need a very stiff frame which can be opened/split in the back to fit the belt. These frames are more expensive to produce which will furthermore increase the overall bike's price.
Ideally, we all train our legs to be able to handle a single speed setup ;-)
... besides the change towards hooks and the react dev team which does not seem to be clear about how to best use them.
The new beta docs just recently changed again removing old best practices concerning dependency arrays in useEffect hooks in favor of a new potential hook called useEffectEvent (which is still experimental).
I love to work with react.
However, it takes _a lot of time_ onboarding new engineers for tasks which are a bit more complicated in nature. Also, using hooks the wrong way can really mess up your product big times.
It would be nice to see react moving in a direction which is by design/architecture less error-prone.
Umidigi is another company to mention. Their Bison models pretty much fill the gap between a massive rugged phone and a standard phone. The phone's battery @~6kmAh usually covers a 2-3 day trip without charging.
To me, the biggest problem with javascript as a backend language is - especially in large teams: people tend to mix backend code with frontend code after a while.
Looking at next.js for example. There are so many ways to fetch data for a page:
getStaticProps, getInitialProps, getServerSideProps and the API handler (I hope I didn't miss any now). Each single one of those uses their own naming concepts (context vs req/res, query vs params). It is very easy - especially for newcomers to the frontend - to break things or leak data by not following the concepts of the frontend.
By dividing backend and frontend on a language level, you get a clear boundary on an API level which helps developers having a clear focus on their actual problem scope.
I guess you could solve the problem by having two node.js applications: one providing API endpoints and one taking care of the view. By then, I'd just switch to a properly type-safe language for the backend.
(You might be able to find an older version for free)
Disclaimer: I've been participating in a Systems Engineering master program @ university a while back which was based on both Haberfellner (and is finally available in English also) and Incose.
My current setup:
- generate a new psql testcontainer _or_ reuse an existing one by using a fixed name for the container - connect to the psql container with no database selected - create a new database using a random database name - connect to the randomly generated database - initialize the project's tables - run a test - drop the database - keep the testcontainer up and running and reuse with next test
With this setup, most tests run sub-second;