joaogarin
commented
7 years ago This sounds like a really great idea.. I feel like the second option is more appealing.as the first one probably will hit the wall on some users. I dont feel like having to build the app once you design a new model or change existing ones. But yeah designing this is probably a good idea.
In the end people need to build an app, they have requirements from their bosses in terms of not only design but features etc so contenta needs to be able to provide that, so probably having this as a "kick off" point for development on a new feature is more suitable.
I have two questions though maybe regarding it..and the more generalized "who is this for"..in terms of not only the frontends but also contenta itself.
1 ) Does this change in some way who we are targeting with contenta? I mean the idea from what I get of the out-of-the-box initiative plays really well with this idea. It doesnt really get more out-of-the-box then you are describing, but does it require a really well rounded developer to use it? And if so, does that go against contanta's use case. Lets maybe discuss it in the channel.
2 ) Regarding configuration, how much does this go in terms of configuration for the user. Contenta as I read from the channel is a configuration free solution. that sounds like the golden rule from what I read so again maybe something to check on the channel
In general I think this is a great idea, if we can pull it off this would be really an amazing solution. I think all frontends should probably go in the same direction so there might be interest in other frontends to follow this approach and we could all work in this design document?
e0ipso
mrjmd
This was a topic of a lot of discussion with the Angular team. The basic premise is that building an app to consume and display known and established data models (a recipe site) is all well and good, but the ideal scenario is a (service / library / application / whatever) that can respond to changing data models and whole new data models dynamically.
On the Drupal side, this means that for each data model we would want a schema exposed, which should already be being generated by the OpenAPI integration, we'd just need those to be directly addressable / linked to from the /api endpoint perhaps.
On the front end side, there were two possible approaches to this that we discussed, which can be broken into the runtime approach vs the build time approach.
Runtime approach: A (very) rough sketch of this already exists, we hacked it together yesterday here: https://github.com/StephenFluin/contenta_angular/commit/e2af53061bf7f9f9beb99f677e30ba13fb61951e
This approach ~ works, but has drawbacks in terms of potential scaling issues, inability to customize templates per data model, etc.
Build time or CLI approach: This idea would be to query for our schemas as a CLI command or build step, and then build out d.ts, component, and template files based on the currently active schemas. This would obviously force a new build each time a field/bundle was added to the site, but would also grant far more customization ability to the user, type checking of templates, etc. Most likely this is the better long term approach but we might want to diagram out a design doc to make sure the idea is fully fleshed out before attempting an implementation.