Please don't do this without typescript and strong types.
At first config objects seems like a great idea to simplify and write less repetitive code. However, leaning too heavily on them can lead to rigid janky code to handle new cases and edge cases.
The dev experience becomes terrible when your coworkers have to read through hundreds of lines of config object parsing methods.
The time you initially thought you'd save is lost again to debugging and trying to find some undocumented setting or side effect that's not working as you expect.
IMO config objects are best when they are simple, self documenting, and no more than one or two layers deep
You're 100% correct, the idea is nice and will definitely save some time at the beginning, but with time and team growth, it becomes quite a mess specially if there's no proper documentation on how to use such files, and no one documents their work... Right now I'm working for a company that uses this approach, with old javascript split in different repositories, it is really impossible to debug and sometimes I take days just to find the right piece of code to update.
This is absolutely a great call! Given the amount of data that can be condensed on such objects, skipping one or 2 props will eventually happen. Having typescript (or any other type system) is a MUST.
FYI, Meta-System is made with typescript under the hood, and I'm glad I used it.
Nice! If your config objects are created and consumed strictly by software (which I assume is likely the case if you're doing language translation) then these problems probably won't put as much burden on developers.
My feelings mostly come from projects I've implemented where developers were intended to create the configs. Not having strong enough types as a POC lead to needing a big refactor to improve discoverability of features for developers.
Common case of a POC mutating from "hey this could save us time" into "all my time is spent maintaining and documenting" 🤣
Using typescript for this seems a very good idea indeed ... JSON-schema maybe?
And I can imagine that at some point you'd also want some sort of a graphical editor, so that you can edit a "model" in a meaningful way (MDD, model-driven development) ...
I must say that when I saw the big blob of JSON that's needed for even a pretty simple app it gave me a bit of a headache, I can't imagine that it will really be a joy to "program" like that. Some sort of higher-level editor support would alleviate that ... and the ability to split the JSON declaration into separate files or "components".
The way I could really see this working is that you'd use a JSON model to generate the repetitive, boiler plate kind of stuff within your app, then the more "interesting" logic would still be coded in a conventional programming language.
Well this does look like MDD (Model Driven Development) all over again.
Please don't do this without typescript and strong types.
At first config objects seems like a great idea to simplify and write less repetitive code. However, leaning too heavily on them can lead to rigid janky code to handle new cases and edge cases.
The dev experience becomes terrible when your coworkers have to read through hundreds of lines of config object parsing methods.
The time you initially thought you'd save is lost again to debugging and trying to find some undocumented setting or side effect that's not working as you expect.
IMO config objects are best when they are simple, self documenting, and no more than one or two layers deep
Edit:typo
You're 100% correct, the idea is nice and will definitely save some time at the beginning, but with time and team growth, it becomes quite a mess specially if there's no proper documentation on how to use such files, and no one documents their work... Right now I'm working for a company that uses this approach, with old javascript split in different repositories, it is really impossible to debug and sometimes I take days just to find the right piece of code to update.
This is absolutely a great call! Given the amount of data that can be condensed on such objects, skipping one or 2 props will eventually happen. Having typescript (or any other type system) is a MUST.
FYI, Meta-System is made with typescript under the hood, and I'm glad I used it.
Nice! If your config objects are created and consumed strictly by software (which I assume is likely the case if you're doing language translation) then these problems probably won't put as much burden on developers.
My feelings mostly come from projects I've implemented where developers were intended to create the configs. Not having strong enough types as a POC lead to needing a big refactor to improve discoverability of features for developers.
Common case of a POC mutating from "hey this could save us time" into "all my time is spent maintaining and documenting" 🤣
Using typescript for this seems a very good idea indeed ... JSON-schema maybe?
And I can imagine that at some point you'd also want some sort of a graphical editor, so that you can edit a "model" in a meaningful way (MDD, model-driven development) ...
I must say that when I saw the big blob of JSON that's needed for even a pretty simple app it gave me a bit of a headache, I can't imagine that it will really be a joy to "program" like that. Some sort of higher-level editor support would alleviate that ... and the ability to split the JSON declaration into separate files or "components".
The way I could really see this working is that you'd use a JSON model to generate the repetitive, boiler plate kind of stuff within your app, then the more "interesting" logic would still be coded in a conventional programming language.
Well this does look like MDD (Model Driven Development) all over again.
I can definitely say that we're on the same page :)
All of this is on the Meta-System's Roadmap, which you can check it here.
I see it! "Meta-System configuration can be split in multiple files"