I am looking for a solution to extend my Ember application during runtime by consuming data and how the data is to be rendered.
It is pretty clear to me that there are different ways of achieving this. Yet, I am not sure what is the coolest and most manageable way of achieving this.
Let me explain my situation:
I have a boring Ember application which loads in the browser and communicates with an API service to consume the data to be rendered. For the most obvious structural data and its relations, it works pretty well.
However…
The API can be extended by business analysts to produce further JSON-encoded reports using auxiliary procedures and DSLs almost on an ad-hoc basis as requirements arise. This backend process is well streamlined. So far so good…
Once a new report is added to the repertoire, the Ember application obviously needs to have a route (and/or component) defined which consumes the data and renders it. This exercise is pretty boring and usually quite repetitive with lots of boilerplate stuff in my case.
I would rather like that business analyst exposes the report as a (data, view) tuple as she has an idea about how the data is to be displayed. She is smart and quick learner, so she can learn how to define a view such as a table, list, plot, and compositions of them, and so on. As long as it is practical, not too much work and not irrelevant to her occupation and domain expertise…
Now, is there a Web standard which is also applicable in Ember ecosystem which would be ideal in the design and implementation for a cool and manageable solution to my requirement, in particular to define data and views, and then render them in an Ember application on demand?
If not, what could be best practices in this case? Or should I start doing what I think is good enough?