Feature/custom translations frontend #857

rvveber · 2025-04-08T14:25:37Z

Adds the possibilty to inject/override custom translations at runtime.

src/frontend/apps/impress/src/core/config/ConfigProvider.tsx

docs/customization.md

src/frontend/apps/impress/src/features/language/hooks/useTranslationsCustomizer.ts

docs/customization.md

src/frontend/apps/impress/src/features/language/hooks/useTranslationsCustomizer.ts

src/frontend/apps/e2e/__tests__/app-impress/config.spec.ts

src/frontend/apps/impress/src/features/language/hooks/useTranslationsCustomizer.ts

AntoLC · 2025-05-16T13:42:47Z

src/frontend/apps/impress/src/features/auth/api/types.ts

@@ -11,5 +11,5 @@ export interface User {
  email: string;
  full_name: string;
  short_name: string;
-  language: string;
+  language?: string;


language can be undefined from the backend ?

Yes, language is nullable.
It was introduced with the language synchronization feature and should've been changed back then.

It allows us to update the users preferred language automatically from the i18n browser detected language - without overriding his existing preference.

AntoLC · 2025-05-16T13:45:18Z

src/frontend/apps/impress/src/features/language/hooks/useCustomTranslations.ts

+  const currentCustomTranslations: Resource = useMemo(
+    () => currentConfig?.theme_customization?.translations || {},
+    [currentConfig],
+  );
+


Suggested change

const currentCustomTranslations: Resource = useMemo(

() => currentConfig?.theme_customization?.translations || {},

[currentConfig],

);

const currentCustomTranslations: Resource = currentConfig?.theme_customization?.translations || {};

AntoLC · 2025-05-16T13:46:42Z

src/frontend/apps/impress/src/features/language/hooks/useCustomTranslations.ts

+  return {
+    currentCustomTranslations,
+    customizeTranslations,
+  };
+};


You don't seem to need to export them.

AntoLC · 2025-05-16T13:47:57Z

src/frontend/apps/impress/src/features/language/hooks/useCustomTranslations.ts

+  );
+
+  useEffect(() => {
+    if (currentCustomTranslations) {


currentCustomTranslations seems everytime defined.

Suggested change

if (currentCustomTranslations) {

AntoLC · 2025-05-16T13:51:18Z

src/frontend/apps/impress/src/features/language/hooks/useSynchronizedLanguage.ts

+
+  const availableFrontendLanguages = useMemo(
+    () => Object.keys(i18n?.options?.resources || { en: '<- fallback' }),
+    [i18n],


Suggested change

[i18n],

[i18n?.options?.resources],

AntoLC · 2025-05-16T13:59:01Z

src/frontend/apps/impress/src/features/language/hooks/useSynchronizedLanguage.ts

+      log('Updating backend language (%O)', {
+        requested: language,
+        from: user.language,
+        to: closestBackendLanguage,
+      });


Should be just during the development part I think.

AntoLC · 2025-05-16T14:00:36Z

src/frontend/apps/impress/src/features/language/hooks/useSynchronizedLanguage.ts

+      log('Updating frontend language (%O)', {
+        requested: language,
+        from: i18n.resolvedLanguage,
+        to: closestFrontendLanguage,
+      });
+      void i18n.changeLanguage(closestFrontendLanguage);


Same it is part of the development part, should be removed.

AntoLC · 2025-05-16T14:06:19Z

src/frontend/apps/impress/src/features/auth/api/useAuthMutation.ts

+function createUser(): Promise<User> {
+  throw new Error('Not yet implemented.');
+}


We are creating things that we don't need yet (maybe never ?), same for the deleteUser.

After this feature is made to manage the authentication, I don't know if it is the good place to add the user mutation.

Thanks for your valuable feedback on the useAuthMutation pull request. I appreciate you highlighting the concerns around the scope and placement of the user-related mutations.

I agree with your observations, and I believe a couple of changes will clarify the intent and improve the structure:

Renaming for Clarity:

You're right, the current names are a bit misleading. I propose renaming:

useAuthQuery to useUserQuery

getMe to readUser (which will default to fetching /users/me/ but could accept an ID).

useAuthMutation to useUserMutation.

This better reflects that we are fundamentally querying and mutating User data.

Relocation to Entity-Specific Path:

Following the renaming, I'll move these hooks to a more appropriate location, such as api/entities/user/. This aligns with the idea that these are general-purpose tools for managing the User entity, not strictly tied to the authentication feature's codebase.

Regarding createUser and deleteUser:

My intention in including createUser and deleteUser (even as unimplemented stubs for now) within useUserMutation was to:

Establish a Complete CRUD Pattern: Provide a full, standard interface (Create, Read, Update, Delete) for the User entity from the outset. This is a common and robust pattern, similar to what one might find in ORMs, and it makes the API for User management predictable.

Serve as a Clear Blueprint: This structure acts as a boilerplate, clearly defining how all entity mutations should be handled. It sets an example for consistency when we add mutations for other entities in the future.

Enhance Readability & Single Responsibility: Grouping all mutation logic for a User (create, update, delete) within useUserMutation maintains a clear single responsibility for modifying user data. I believe this makes the code more self-documenting and easier to navigate.

Future Preparedness with Minimal Overhead: While these functions aren't used by the current feature iteration, defining them now prepares us for future requirements. The stubs themselves add negligible overhead but offer significant structural benefits and clarity for ongoing development.

By renaming and relocating these hooks to focus on the User entity, I believe the inclusion of the full CRUD set (even with stubs) becomes more logical as it defines the comprehensive API for User management.

I've spent considerable time researching best practices for data fetching and mutations in React, and this pattern of co-locating entity-specific hooks with a complete operational set seemed the most explicit and maintainable.

Please let me know if these proposed changes and this explanation address your concerns.
I'm keen to ensure we're building a clean and scalable foundation.

We have agreed to simplify it to useUpdateUser that does not follow CRUD explicitly.

AntoLC · 2025-05-16T14:08:33Z

src/frontend/apps/impress/src/features/language/hooks/useSynchronizedLanguage.ts

+    currentBackendLanguage,
+    currentFrontendLanguage,
+    changeLanguageSynchronized,
+    currentUser,


Is currentUser necessary ?

AntoLC · 2025-05-16T14:16:11Z

src/frontend/apps/impress/src/features/language/hooks/useSynchronizedLanguage.ts

+    [changeBackendLanguage, changeFrontendLanguage, currentUser],
+  );
+
+  useEffect(() => {


I have the feeling this useEffect is trigger often.

It was not good to have the useEffect in the useSynchronizedLanguage hook anyways,
as it added 1 useEffect call, everytime useSynchronizedLanguage() is instantiated.

To counteract, one would need to develop a Provider to share Context.
Since i didn't see the need for a dedicated Provider just to prevent a race condition / enable singleton pattern, i instead moved the useEffect to the ConfigProvider and simplified useSynchronizedLanguage to only be responsible for change language.

The default behavior ("sync frontend detected language to backend if backend language is null") is now handeled in the ConfigProvider. It looks more on par with what we already have in there.

Part of customization PoC Signed-off-by: Robin Weber <[email protected]>

Introduces dedicated mutations (for authentication/user operations) separating them from queries to align with best practices for data fetching and state management. Queries remain responsible for READ operations, while mutations now handle CREATE, UPDATE, and DELETE actions (for user data) improving separation of concerns. Signed-off-by: Robin Weber <[email protected]>

- Refactors "useTranslationsCustomizer" to "useCustomTranslations" - Refactors "useLanguageSynchronizer" to "useSynchronizedLanguage" - Refactors "LanguagePicker" to better reflect its component role - Refactors "LanguagePicker" to use "useSynchronizedLangue" - Removes unused "useChangeUserLanguage" - To change the user language, use "useAuthMutation" instead Signed-off-by: Robin Weber <[email protected]>

- Language will only be changed if different from current language - Added test for custom translations Signed-off-by: Robin Weber <[email protected]>

rvveber force-pushed the feature/custom-translations-frontend branch 2 times, most recently from 10cd759 to d285bd1 Compare April 8, 2025 14:36

rvveber mentioned this pull request Apr 8, 2025

✨Process overriding Docs #799

Open

9 tasks

rvveber force-pushed the feature/custom-translations-frontend branch 2 times, most recently from 4ff16fa to 81fd1ed Compare April 8, 2025 15:12

AntoLC requested review from AntoLC and lunika April 8, 2025 15:19

AntoLC reviewed Apr 9, 2025

View reviewed changes

rvveber force-pushed the feature/custom-translations-frontend branch 2 times, most recently from b9b16aa to 06b91a1 Compare April 14, 2025 17:14

rvveber requested a review from AntoLC April 14, 2025 17:14

rvveber force-pushed the feature/custom-translations-frontend branch from 06b91a1 to af92119 Compare April 16, 2025 10:47

AntoLC reviewed Apr 22, 2025

View reviewed changes

src/frontend/apps/e2e/__tests__/app-impress/config.spec.ts Outdated Show resolved Hide resolved

src/frontend/apps/impress/src/features/language/hooks/useTranslationsCustomizer.ts Outdated Show resolved Hide resolved

rvveber force-pushed the feature/custom-translations-frontend branch 2 times, most recently from a65fca6 to cddc429 Compare May 7, 2025 14:21

rvveber requested a review from AntoLC May 7, 2025 14:26

rvveber force-pushed the feature/custom-translations-frontend branch from cddc429 to 9a9b717 Compare May 7, 2025 14:28

rvveber marked this pull request as draft May 8, 2025 09:44

rvveber force-pushed the feature/custom-translations-frontend branch 3 times, most recently from 5f855f1 to ed137ef Compare May 8, 2025 17:53

rvveber marked this pull request as ready for review May 8, 2025 17:57

rvveber force-pushed the feature/custom-translations-frontend branch from ed137ef to 2e7f552 Compare May 12, 2025 14:52

rvveber marked this pull request as draft May 12, 2025 14:58

rvveber force-pushed the feature/custom-translations-frontend branch from 2e7f552 to 6a036b3 Compare May 12, 2025 15:02

rvveber marked this pull request as ready for review May 12, 2025 15:22

rvveber force-pushed the feature/custom-translations-frontend branch from 6a036b3 to 6a75453 Compare May 12, 2025 15:43

rvveber mentioned this pull request May 12, 2025

Feature/query caching and debug flags #961

Draft

rvveber force-pushed the feature/custom-translations-frontend branch 2 times, most recently from 0080fdc to bf65c8b Compare May 13, 2025 10:51

rvveber force-pushed the feature/custom-translations-frontend branch 3 times, most recently from d86f811 to f7abb03 Compare May 13, 2025 11:23

AntoLC reviewed May 16, 2025

View reviewed changes

rvveber force-pushed the feature/custom-translations-frontend branch from f7abb03 to 4d59da8 Compare May 27, 2025 15:15

rvveber requested a review from AntoLC May 27, 2025 15:20

✨(frontend) Adds customization for translations

fb6e86c

Part of customization PoC Signed-off-by: Robin Weber <[email protected]>

rvveber force-pushed the feature/custom-translations-frontend branch 2 times, most recently from 8c383a0 to 372b8d9 Compare May 27, 2025 15:42

rvveber added 4 commits May 27, 2025 17:46

📝(documentation) adds customization for translations

00677eb

Part of customization PoC Signed-off-by: Robin Weber <[email protected]>

✅(tests) Add & adapt language tests

bb1c96e

- Language will only be changed if different from current language - Added test for custom translations Signed-off-by: Robin Weber <[email protected]>

rvveber force-pushed the feature/custom-translations-frontend branch from 372b8d9 to bb1c96e Compare May 27, 2025 15:47

Feature/custom translations frontend #857

Are you sure you want to change the base?

Feature/custom translations frontend #857

Conversation

rvveber commented Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rvveber May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rvveber May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rvveber commented Apr 8, 2025 •

edited

Loading

rvveber May 20, 2025 •

edited

Loading

rvveber May 27, 2025 •

edited

Loading