4 ms·
I beg your pardon? Even translation of pure text (and not numbers, date, currency) relies on locale data, like plurals and genders. It's just way more elegant t
by eliseumds 5y ago
I beg your pardon? Even translation of pure text (and not numbers, date, currency) relies on locale data, like plurals and genders. It's just way more elegant to have this data inside a React context instead of importing a global translator or passing in locale data whenever needed (dangerous repetition).
- aniforprez 5y agoI genuinely don't understand this comment or the reason for writing it as a hook or a separate component in the article Why wouldn't you just write it as a function with data and context being passed through as arguments? Isn't it much simpler to write a pure function and test that function than render a component and test it? If you simply write a function that accepts the locale, the string and context, does the translator magic and returns the translated text, would you not then just need to write a unit test simply to make sure you're getting the expected output? Why the abstraction into hooks and then further into a separate component that you then have to render?
- eliseumds 5y agoIt doesn't matter what your code is doing inside that component, you can still make it easily testable by having the core translation pipeline as pure functions. See https://news.ycombinator.com/item?id=27031847 https://news.ycombinator.com/item?id=27031847 for more reasons.
- activitypea 5y agoWhat's "elegant" about putting it in a React Context? Outside of initial configuration, it's a stateless function. Just chuck it in a separate module and have some initialisation code. Nothing about it demands that it live in the component tree.
- eliseumds 5y agoIt is not that simple. You could use the exact module in different environments: browser, NodeJS, React Native. If you don't use context, you either need to do some very ugly module replacement at build time or duplicate your code. Also, you lose lifecycle hooks (not that important in this case though).
- activitypea 5y agoCoupling it to React Context makes it easier to reuse in Node? I beg your pardon? :) If you plan to reuse it in different environments, just give the user a `setConfiguration` and a `translateFunction` function. I prefer module-level variables for holding the i18n system state, but it could also be a class-based singleton, if that's your cup of tea. I still don't see how React plays into this.
- eliseumds 5y agoWhat's your programming background? This is some quite basic stuff to be honest. Have you heard of dependency injection? Context is dependency injection in React, there you go. There's quite a few .Net/Java books that would offer you better examples and clearer reasoning than myself, like this one: https://www.manning.com/books/dependency-injection-principles-practices-patterns https://www.manning.com/books/dependency-injection-principle....
- activitypea 5y agoDon't talk down to people, even when you doubt them. It's not a good look :) Context is an application of the principles behind DI, sure, but that doesn't really address my point.
- eliseumds 5y agoSorry if you felt talked down. I am lucky to have worked in some very big and complex React applications and will share more experience with you: * By using a singleton you're not able to easily test different LocaleData contexts in parallel. * By using a singleton you're not able to make your NodeJS server deal with users with different locale settings because you have only one global instance. Multiple requests arriving at the same time would corrupt each other. You could spawn a separate process for each locale but that's inconvenient. Does that make sense?
- zarathustreal 5y agoDependency injection in modern programming is known as "partial function application" and the poster you're replying to is correct. React Context is not at all an elegant solution, it's the opposite. It's a hard coupling to hidden global state.