Doc fixes (#1385)

docs/docs/developer/frontend/best-practices.mdx

@@ -42,7 +42,7 @@ We do not recommend using `useRef` to store state.
 
 If you want to store state, you should use `useState` or `useRecoilState`.
 
-We recommand seeing [how to manage re-renders](#managing-re-renders) if you feel like you need `useRef` to prevent some re-renders from happening.
+We recommend seeing [how to manage re-renders](#managing-re-renders) if you feel like you need `useRef` to prevent some re-renders from happening.
 
 ## Managing re-renders
 
@@ -56,7 +56,7 @@ Keep in mind that re-renders can **always** be avoided by understanding the caus
 
 We made it easy for you to avoid re-renders in new features by taking care of eliminating them at the root level.
 
-There's only one `useEffect` in the sidecar component `AuthAutoRouter` that is holding all the logic that should be executed on a page change.
+There's only one `useEffect` in the sidecar component `PageChangeEffect` that is holding all the logic that should be executed on a page change.
 
 That way you know that there's only one place that can trigger a re-render.
 
@@ -147,8 +147,6 @@ We do not recommend `React.memo()` usage because it does not solve the cause of
 
 They are often not necessary and will make the code harder to read and maintain for a gain of performance that is unnoticeable.
 
-
-
 ## Console.logs
 
 `console.log` statements are invaluable during development, offering real-time insights into variable values and code flow. However, leaving them in production code can lead to several issues: 
@@ -187,18 +185,18 @@ const [email, setEmail] = useState('');
 
 ### Event handlers
 
-Event handler names should start with `handle` instead of `on`
+Event handler names should start with `handle`, `on` is a prefix used to name events in components props
 
 ```tsx
 // ❌ Bad
-const onEmailChange = (val: string) => {
+function onEmailChange(val: string) {
   // ...
 }
 ```
 
 ```tsx
 // ✅ Good
-const handleEmailChange = (val: string) => {
+function handleEmailChange(val: string) {
   // ...
 }
 ```
@@ -218,7 +216,7 @@ type OwnProps = {
 };
 
 function EmailField({ value, disabled = false }: OwnProps) {
-  return <TextInput value={value} disabled fullWidth />;
+  return <TextInput value={value} disabled={disabled} fullWidth />;
 }
 ```
 
@@ -248,13 +246,7 @@ Prop drilling, in the React context, refers to the practice of passing state var
 
 3. **Reduced Component Reusability**: A component receiving numerous props solely for the purpose of passing them down becomes less general-purpose and harder to reuse in different contexts.
 
-To combat excessive prop drilling:
-
-- **Context API**: Consider using React's Context API for state that needs to be accessed by many components throughout your app.
-  
-- **Component Composition**: Refactor components to minimize deep nesting or make use of render props to share stateful logic.
-
-- **Utilize Recoiljs**: Recoiljs is a state management tool for React. By using atoms and selectors, it streamlines shared state access, reducing the need for prop drilling, and enhances component organization and performance.
+If you feel that you are using excessive prop drilling, see [state management best practices](/developer/frontend/best-practices#state-management)
 
 ## Imports
 

docs/docs/developer/frontend/overview.mdx

@@ -35,7 +35,7 @@ We took care of having a clean and simple stack, with minimal boilerplate code.
 
 We use [React Router](https://reactrouter.com/) for routing. 
 
-To avoid unnecessary [re-renders](/developer/frontend/best-practices#managing-re-renders) we handle all the routing logic in a `useEffect` in `AuthAutoRouter`.
+To avoid unnecessary [re-renders](/developer/frontend/best-practices#managing-re-renders) we handle all the routing logic in a `useEffect` in `PageChangeEffect`.
 
 ### State Management
 

docs/docs/developer/frontend/style-guide.mdx

@@ -129,30 +129,30 @@ type MyType = {
 };
 ```
 
-### Fixed constant sets
+### Use string literals instead of enums
 
-For situations where a value anticipates a fixed set of constants, it’s advisable to define enums over union types.
+[String literals](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types) are the go-to way to handle enum-like values in TypeScript. They are easier to extend with Pick and Omit, and offer a better developer experience, especially with code completion.
 
-**Why Opt for Enums Over Union Types**
-
-Enums offer a structured approach to representing a set of related values in TypeScript. Unlike union types, which can become cumbersome as the list grows, enums centralize and group values under a coherent label. This not only improves readability but also simplifies maintenance, as any change only requires an update in one place. Furthermore, enums provide semantic context, making it clear that the values are part of a unified set, thereby enhancing clarity and reducing potential for errors.
+You can see why TypeScript recommend avoiding enums here : https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#enums
 
+However, GraphQL codegen will generate enums, so you can't avoid them completely, but avoid creating new ones.
 
 ```tsx
-// ❌ Bad, utilizes a union type
-let color: "red" | "green" | "blue" = "red";
-```
-
-```tsx
-// ✅ Good, utilizes an enum
+// ❌ Bad, utilizes an enum
 enum Color {
   Red = "red",
   Green = "green",
   Blue = "blue",
 }
+
 let color = Color.Red;
 ```
 
+```tsx
+// ✅ Good, utilizes a string literal
+let color: "red" | "green" | "blue" = "red";
+```
+
 ## Styling
 
 ### Use StyledComponents