Organization of work in the project

[OskarZaremba]

I think that with the expanding janush code and the high rotation of programmers in the team, a some sort of rules for writing code would be useful.

Below I am giving my suggestion about the topics that came to my mind and I think it would be worth discussing them. These are the following:

Rules for naming: files, variables, constants, functions, classes - E.g. written in what notation: camelCase, snake_case, PascalCase?

Rules regarding module imports - E.g. imports from external modules, first and our modules are separated by an empty line and are below plus e.g. imports sorting alphabetically? There is even nice plugin that helps organising that which is -> eslint-plugin-import

Rules for module exports - E.g. export const myFunction ... or at the bottom of the file and export all {myFunction, func1, etc.}?

Rules for writing functions - E.g. const myFunc = () => {} or function myFunc () {} if both then which and when?

Rules regarding types and interfaces - E.g. if a given type / interface is used only in the file in which we create it, whether we keep it in this file or create a directory for the whole and we have the file with types / interfaces separately and the class / function separately in separate files?

Rules regarding code review - E.g. in addition to the correctness of the code, maybe we could check as well the above rules set in the project for better consistency of code?

[piotrmoszkowicz]

Rules for naming: files, variables, constants, functions, classes - E.g. written in what notation: camelCase, snake_case, PascalCase?

• I obviously agree, it should be added into CONVENTIONS.md

Rules regarding module imports - E.g. imports from external modules, first and our modules are separated by an empty line and are below plus e.g. imports sorting alphabetically? There is even nice plugin that helps organising that which is -> eslint-plugin-import

• I think we have it already in CONVETIONS.md. Unfortunatelly I am unsure if eslint-plugin-import is sophisticated enough to take all of our rules into consideration.

Rules for module exports - E.g. export const myFunction ... or at the bottom of the file and export all {myFunction, func1, etc.}?

• I would use first option.

Rules for writing functions - E.g. const myFunc = () => {} or function myFunc () {} if both then which and when?

• I would use first option.

Rules regarding types and interfaces - E.g. if a given type / interface is used only in the file in which we create it, whether we keep it in this file or create a directory for the whole and we have the file with types / interfaces separately and the class / function separately in separate files?

• For props I would have it in the same file. Usually I would put them in same file unless they are reused.

Rules regarding code review - E.g. in addition to the correctness of the code, maybe we could check as well the above rules set in the project for better consistency of code?

• Would be nice to have bot checking for that, I agree.

There are also some more things (some may be duplicates):

1. Use yarn / npm in all parts of the application (currently docosaurus for example uses yarn).
2. Add return types wherever they are missing.
3. stubArg -> can be generic, do not use any.
4. Use interface instead of types.
5. File naming convention - I would suggest camelCase.
6. readJanushJSON - throw new Error() - add more descriptive exception.
7. Look thru all commented code / TODOs.
8. ConfirmSignUp.text.tsx.template - why var?
9. Decide between React.VFC and JSX.Element and be consistent.
10. Use React.VFC instead of React.FC if you are not accepting children.

[OskarZaremba]

Regarding rules of imports. It seems that plugin mentioned by me is sophisticated enough to introduce our rules and if not then I think we could modify the rules slightly. In my opinion it is always better to have something automatically done and unified rather than have excellent rules but not followed everywhere causing some sort of mess;)

[OskarZaremba]

Additionally, about imports, I see that sometimes we import like this -> import {FC} from "react"; and then const App: FC, and sometimes like this -> import React from "react"; and then const App: React.FC. Personally, the first method seems more concise :) Do we have any scripts or code snippets that generate components for us? It seems to me that it would be best to add a script to the project so that everyone can use it and then all components will be generated the same way :)

[OskarZaremba]

Maybe we could review the code and change some utils to more generic ones? Eg readJanushJSON only reads one selected json file.

[piotrmoszkowicz]

Jeśli chodzi o importy - jak plugin śmiga to jestem w 100% za. Drugi komentarz - pick one, myślę, że każdemu będzie okej z tym, ważne, żeby było spójnie. Jeśli chodzi o trzeci komentarz - trochę nie do końca rozumiem - masz na myśli, żeby ta funkcja mogła robić więcej i była bardziej generyczna? A mamy taką potrzebę? Może zmienić, że to nie utils tylko coś innego?

[OskarZaremba]

I had to introduce another readJson function in order to read schema.json file so now there is my function readJson and readJanushJson. If I can I think we should refactor and use only one function.