ThaNarie
commented
4 years ago I'm not opposed to the idea of allowing more freedom, that's why any yaml/json data file can also be changed to a .js file, that can either export an object or a function that returns an object.
See https://github.com/mediamonks/muban/blob/a5425f2fb41147d443f4be412d056164cc0c0e27/src/data/test.js and https://github.com/mediamonks/muban/blob/a5425f2fb41147d443f4be412d056164cc0c0e27/src/app/component/block/paragraph/data.js and in the documentation.
yaml/json have the advantage of being usable as easy documentation or used in other scripts to sync up data requirements between the FE and BE, without those scripts having to rely on parsing or generating javascript. So those options will always stay there.
I like to explore though how we can make the error-catching of yaml/json a better experience though, either by providing schemes, or validation hooks.
TypeScript Adding support for TypeScript might be a bit more tricky, since these files are also processed during build-time in node itself, which adds a lot of complexity.
A solution for this could be to process all the data files in the webpack stage, and loading that file in the build step which would provide the data as plain objects.
Muban is currently very configuration centric using Yaml/Json files for pages and data mocking. That means developers lose the ability to write logic to adapt to specific project needs. Yalm/Json files also take away type-safety and tend to fail later (or silently) rather than failing on compile time.
I don't know in depth why Muban is architected in this way or what the constraints were that lead to this design, but I would like to at least pose the idea of using Typescript files for data mocking and page setup.