Open jstet opened 9 months ago
I agree. I think we should try to scope some specific stability/quality goals and then address them in sub-issues. Coordinated from here.
I think the scoping is important because as mentioned above one can always write more tests, increase quality and stability.
Possible ways to scope on the Coding/JS related refactoring
I think the Infrastructure part is already scoped pretty well an can be turned into sub-issues quite well.
Static build now includes all assets
We could implement testing with Storybook and add a documentation like this: https://www.wix-pages.com/wix-design-system-employees/
Next task is to standardize and improve parsing of cms data.
The goal is to sep. data processing and type checking/completeness checking. For the latter, typescript would come in handy: https://www.typescriptlang.org/docs/handbook/interfaces.html
Problem: fields in directus are not camelcase
At the moment we declare data fields in three places: in the graphql query, the rendering functions and in the components.
We are going to use: https://github.com/jquense/yup
Furthermore, all function should be documented
I am going to merge the existing work and implement yup in a sep. branch
implement a better component structure (e.g. one folder for cards)
Add way more tests
As there are currently mostly @KonradUdoHannes (on a volunteer basis) , @friep (who is understandably very busy with other important things) and me (who works 6h a week) working on the website, the capacity to fix bugs and react to infrastructure failures is limited. Also, the codebase is getting more and more complex. Therefore I would like to invest some time into cleaning up and increasing the stability of the website and associated infrastructure (directus). This includes:
Coding/Javascript related
Adding more unit and e2e tests: In the recent past, some bugs were introduced with changes to the code that could have been avoided with more tests. For example some svg icons were invisible suddenly because i accidentally deleted a line of code. But there is a limit to how much tests we can write and we cant cover everything.
Generally cleaning up the code:
extend/improve abstract explanation of how the website works/where to find things
Directus/ Infrastructure related
https://github.com/CorrelAid/correlaid_website/issues/505 : website wont display images when our directus instance is down.
Move the state of the IaC code (directus on vps with connected managed db) to some remote storage so I am not the only one able to change it.
Add simple observability to the directus instance (dashboard with basic metrics so we know whether it has enough resources/is stable). Maybe DO graphs are enough.
Add basic notifications in case directus is down. (send an email)
How do we handle updates of the directus software?