Replies: 18 comments
-
|
Hi Sebastian, Your solution works, but there are some issues:
Ok, the use of the extraction tool is not mandatory, and we could think about offering type safe. But how? I could add another overload to the return function of where V is the return type, and K the key type. But then you should always create a type for each scope in your app and pass it to each translation:
and in component:
EDIT and in component:
A curiosity: why are there values of type |
Beta Was this translation helpful? Give feedback.
-
|
Hi Robi,
yes I understand the approach of the library. I have to figure my mind
around it, how to include the type safety for the values but keep the
original functionality.
The number in the object is just an example. Nowadays I use Chat-GPT a lot
to help me with types. It comes up with good ideas when you prompt it
correctly. It is not that far, means you need some cycles and the prompt
basis must be correct.
Another option that came to my mind was to start a file watcher to generate
an type in the background when a json file in the i18n changes and then
apply the provided utitilty types to it.
I don't know what you think about this approach? I guess it would keep the
original functionality and the computing costs should be quiet low.
So I wish you a nice thursday. Hear you soon.
Sebastian
Am Mi., 24. Mai 2023 um 23:32 Uhr schrieb Roberto Simonetti <
***@***.***>:
… Hi Sebastian,
Your solution works, but there are some issues:
- The approach of this library is different: first the components are
written, and from the components the extraction tool creates json
files (whereas type safe assumes the opposite: first create the files and
then write the components)
- In this library, the keys can also contain the default value (which
is used by the extract tool to create the files)
Ok, the use of the extraction tool is not mandatory, and we could think
about offering type safe. But how?
I could add another overload to the return function of useTranslate:
export type TranslateFn = {
(key: string, params?: Record<string, any>, lang?: string): string;
<V>(key: string, params?: Record<string, any>, lang?: string): V;
<V, K>(key: K, params?: Record<string, any>, lang?: string): V;
};
where V is the return type, and K the key type.
But then you should always create a type for each scope in your app and
pass it to each translation:
export type homeType = Join<PathsToStringProps<typeof
import('../i18n/en-US/home.json')>, ".">;
and in component:
t<string, homeType>('home.text')
But seems very verbose to me. And the inline tool already warns before
going into production if there are any keys without value.
A curiosity: why are there values of type number in your example json?
This library doesn't accept them at the moment! Of course that would be
possible, but what is the use case of non-string values in translation
files?
—
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKLGZZ2TIFRGIVDOMBKJKTDXHZ473ANCNFSM6AAAAAAYN52ZVU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I think we can propose the use of type safe for a scoped component in a way like this: import type { SpeakType } from 'qwi-speak'
export type HomeType = SpeakType<typeof import('../i18n/en-US/home.json'), '.'>;const t = useTranslate<HomeType>();
t('home.text')but you need to create/update the json file before writing the component (a watcher for json files doesn't seem necessary for the compiler and intellisense - at least in vscode) The downside is that the default value and the extraction tool could no longer be used in this case. We should find a way to change the type to accept the default value:
so we could modify the extraction tool to populate the keys already existing in the file with the default values if they are empty or null. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Robi,
I will check that later it should be easily possible to add the default.
So you say it is checked while building the app that the keys in the
language keys match?
I guess an unittest would help a lot of people anyway because you could add
it to a git hook.
Sebastian
Roberto Simonetti ***@***.***> schrieb am Do., 25. Mai 2023,
10:25:
… I think we can propose the use of type safe for a scoped component in a
way like this:
import type { SpeakType } from 'qwi-speak'
export type HomeType = SpeakType<typeof import('../i18n/en-US/home.json'), '.'>;
const t = useTranslate<HomeType>();
t('home.text')
but you need to create/update the json file *before* writing the
component (a watcher for json files doesn't seem necessary for the compiler
and intellisense - at least in vscode)
*The downside is that the default value and the extraction tool could no
longer be used in this case.*
We should find a way to change the type to accept the default value:
t('home.text@@my text')
so we could modify the extraction tool to populate the keys already
existing in the file with the default values if they are empty or null.
—
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKLGZZ52NQ3UPWLBRQMSRB3XH4JOLANCNFSM6AAAAAAYN52ZVU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Why a unit test? to check if the structure of the jsons is equal over all languages? The |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
The Inline plugin runs during the build. I could add an option, which if enabled breaks the build when there are missing keys. So in your git hook, or any other CI method, just run the app build command |
Beta Was this translation helpful? Give feedback.
-
|
Yes that would be feasible the only thing that I fear is that this will take to long to execute. I can add a unittest myself no problem. I was just thinking that others could also benefit from the test when it is included in the library. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Sebastian, I refactored a bit your example, to create an exportable type from the library. It works, but not in all cases, for example when the expected return type is an object or an array Here the repro The best thing would be that the |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Easy? I had tried to use ChatGPT to create this type, but I lost my patience ;) |
Beta Was this translation helpful? Give feedback.
-
|
Yes sometimes it is a bastard :-). I get angry about it from
time to time, too. I mean, it can't really reason about stuff. In the end
it is just a stupid big model of data. You have to review the output
everytime understand the type yourself and then tell it to forget
everything from before and prompt it with your last working version and
your new idea. I think it is worth putting the time into learning how to
interact with it, it really can help with some stuff when you correctly
prompt it. What I also don't like about it is that the knowledge is old.
Planned to try out Bard. Just don't find the time for it.
Am Sa., 27. Mai 2023 um 13:22 Uhr schrieb Roberto Simonetti <
***@***.***>:
… Easy? I had tried to use ChatGPT to create this type, but I lost my
patience ;)
—
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKLGZZ7G6IG5MJMXW4A6JRDXIHPV7ANCNFSM6AAAAAAYN52ZVU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Should we get that type safety into the lib? If you want I can make a draft in the next couple of days and open a pull request for you to review. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Sebastian, I already created a branch: https://github.com/robisim74/qwik-speak/tree/type-safe Here the type: https://github.com/robisim74/qwik-speak/blob/type-safe/packages/qwik-speak/src/types-safety.ts I had to make some changes compared to what you had already done, to make arrays work even when tuple types are not available (like when importing type directly from json). I also added return type matching. It works, but I'm still not very happy with it: the type is very complex, and might cause intellisense to crash on long files. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Robi, what I was thinking about in the morning is if we could build a qwik speak slot that we would pass the props from the speak component down to and then get somehow the type into the scope of the child components without explicitly importing the json what I really don't like about the solution. We could add a vite plugin that uses dynamic imports to bundle a file in development which gets ditched in the prod build. https://stackoverflow.com/questions/52112948/whats-the-return-type-of-a-dynamic-import It seems to be impossible to infer the type into the child component functions. A dynamic import with a variable is not a suitable solution, since we know the value only to runtime. But I always say nothing is impossible. Maybe it is worth to think a little bit more about this. Maybe also you have a good idea when you figure your mind arround it how we could achieve this. Hear you soon, |
Beta Was this translation helpful? Give feedback.
-
|
Hi Robi, did you think about it? Do you think it is feasible to infer the type down? Sebastian |
Beta Was this translation helpful? Give feedback.
-
|
I haven't had the chance to think about it, the solution seems complex and this feature is not strategic: there are still changes and bugs in Qwik and so this library remains in beta version. This is a feature for future stable releases. |
Beta Was this translation helpful? Give feedback.
-
https://www.typescriptlang.org/play?#code/C4TwDgpgBACghsAFgZwCoHsDKwBOBLAOwHMYd0xkAeVAGliggA9gICATZKZXQogbQC6UALxRBAPhFRUDZqw5cexAFBQoAfliqoALmmyW7TugBGAKwgBjYNs0BvbWrV8A0lEJQAosxxxrlAGsIEHQAM2k6bnxicQE9VFchJkMFUwtrDVgEFAxsaJIyCmpEuj4AOgqYOhcBST1yyuqBAG5HKABfPm9cP2BA4LCIxXzY7XqW5WVQSCgAKXRCagN5TijeQToAEWWjYd5JYW0ZZJWxIU0CCAA3CBxdI52FPkJQ26gAMXOP+7VjuV3ngRXnd3nQKmUXm8AErnbTvR6rJRETIAAwAJHZ3u0MZtsXZ5otur5-FDIkiJFtxO0UbooJcbncdNo1sRWlNwNAALIgTYQCBgADy5iswCkDjUoXQ6D04qcJjgOBlbTU8oAXnoWURWk4OtrddoAI4AV0YegIRoAtiZbnrEBAADb26VQWVqMgmPAapF69qtX2TabQXn8lzBKQEgiUeBINBYJGkchUbnBwXC6ziOgAIjKmfErSAA
Originally posted by @Zankel-Engineering in #55 (comment)
Beta Was this translation helpful? Give feedback.
All reactions