Refactoring of code base & developer documentation about thilo HOT 13 CLOSED

• Try to remove unnecessary bloat, simplify layout for more consistent mobile views.
• Simplify API where possible, remove unnecessary fields, move logic away from frontend where possible. I.e. Section#Chapter logic: just include proper parent pointers based on some unique identifier.
• fix ignored URL prefixes
• upgrade react to 17.X or 18.X, resolve dependencies accordingly
• write dev guide after refactoring for (potentially new) dev and prod tooling

from thilo.

Yes, exactly. Now, only production relevant dependencies are used in the build process, and developer dependencies are used during local development.

from thilo.

I agree with the points mentioned above. Lets wait with the dev guide until the rest is done. There should also be a guide in the future how to set everything up in the background @jimmylevell.
I think phoenix mentioned to upgrade to ract 17.x should be enough for this sprint

from thilo.

Totally agree on your listings and your insight. Would write out the dev and admin guide (#65) as soon as the next iteration (0.9) is completed as heavy code quality improvements and simplification are introduced.

I will created a task within the API project to address the admin / dev guide.

• scout-ch/thilo-api#27

from thilo.

Discussed in meeting

• simplify URL (manageability within STRAPI) consider MUI and readable URLs
• Dockerize everything so that it can be easier deployed #80

from thilo.

Please, when adding new dependencies, think about whether they are dev or production dependencies and organize them accordingly.

from thilo.

@broesmel : could you point out which commit you mean where I have added dependencies to the wrong section? As I went through my latest commits and only saw that I have added "serve" cd45a63#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519.

Just that I can fix the wrong assignment. Thank you for pointing out! :)

from thilo.

Hello! Sorry for the delay in answering.

Using "serve" as an example - which is not required in our production server as far as I know. When adding dependencies just used by developers, you can save them globally npm install -g <package_name> and leave them out of the project. Or, if you they are necessary for the development workflow, you can add them to the devDependencies npm install <package-name> --save-dev.
This avoids get compilation errors in case of dependency conflicts and so on.

Thanks!

from thilo.

@aladwani

Is the 'tasks' functionality as ported over the hering project relevant for thilo?

The same I ask myself for the 'targets', and most importantly for the 'links' which are fetched on every load.

edit after meet:
Functionality will be kept until initial content is filled and then we can check on how to maintain it.

from thilo.

I consider this to be mainly done, now waiting for the content to see if everything holds up. The code has some comments now and a dev guide can be created once we are nearing release.

from thilo.

Status of open tasks

• Clear dev dependencies

from thilo.

I think (most of) the dev dependencies need to remain in the project to facilitate development. They are never going into the production code so this should not be too big of an issue.

from thilo.

@broesmel : ok so in this case the following point of yours has been resolved / addressed during your refactoring?

Please, when adding new dependencies, think about whether they are dev or production dependencies and organize them accordingly.

from thilo.