Shared/common locales location? about bulletproof-react HOT 8 CLOSED

Hi there!

Repetitive translations can be shared in src/locales.
As for the feature-specific translations, they can live in their corresponding feature folders and utilize the namespaces feature of i18next.

from bulletproof-react.

Hi @alan2207, many thanks for your replay.
If I got what you said, then:

Feature a
Locales

src/features/a/locales/en/a.json
src/features/a/locales/it/a.json

Usage

t("a:key") or t("key", { ns: "a" })

Feature b
Locales

src/features/a/locales/en/b.json
src/features/a/locales/it/b.json

Usage

t("b:key") or t("key", { ns: "b" })

But what about nested features? How would you handle them?

Feature b (nested inside a)
Locales

src/features/a/features/b/locales/en/???.json
src/features/a/features/b/locales/it/???.json

Usage

t("???:key") or t("key", { ns: "???" })

How would you replace ??? with?

Many thanks again,
Mauro

from bulletproof-react.

Maybe we shouldn't nest features after all. It could make things more complicated in the longer run. I just updated the docs that were recommending it. If you still think it makes your work easier, feel free to nest, but generally, that would be unnecessary.

from bulletproof-react.

@alan2207 thanks for the reply.
What about features depending on other features?

From the routing point of view I have situations such

{APP_URL}/a-entities/{id-a-entity}/b-entities/{id-b-entity}/c-entities/{id-c-entity}

I am tempted to organize things in the following way

/src/features/a/features/b/features/c

Is it better to have one one level also in this situation?

/src/features/a
/src/features/b
/src/features/c

What do you think?

Cheers,
Mauro

from bulletproof-react.

It really depends on the application.

Imagine a social network where you can have users, posts, images, videos, comments, etc.

If it were required that only posts had comments, then I would probably keep comments as part of the posts feature and not extract them into a separate feature.

But if we were required to have comments for posts, images, and videos, it would make sense to have a comments feature as a standalone feature that is compatible and used with posts, images, and videos.

from bulletproof-react.

@alan2207 thanks.

Ok, then I would have only feature A and, in the future, if features B o C are needed elsewhere then I can extract them.
Correct?

Many thanks.

Mauro

from bulletproof-react.

Exactly! Start with the main features of your application and put everything related there. Then you can break it up further once you notice something should be extracted. It doesn't need to be used elsewhere to be a feature, but it needs to solve the business problems of the application. I would suggest you check out domain-driven design and development to get more info and develop intuition about when something should be extracted.

from bulletproof-react.

Thank you!

from bulletproof-react.