Ideas on Data driven UI Composition (vs previous AngularJS approach)

Help Requests
1

Hello,

I’m looking for suggestions on Aurelia techniques for accomplishing this in a clean modular way. I’m very new to all this and starting a greenfield project using Aurelia.

I have an application where some main content area is to be composed of a number of relatively simple custom components that will be chosen based on a property in the supplied data.

The main content area model could be a collection of objects. Each object identifies the type of custom component that should be used to render it (and also the data that component would render). Straight forward enough but I don’t want to hardcode any component/element names. I want them to be controlled by data so that the page is built using the controls the data specifies. They’ll be data input controls in some cases and charts/rendering components in others.

While the concept was simple and dynamic, I gotta think that Aurelia can do this in a little more structured/cleaner way.

Any ideas for me would be great!

Background:

Here’s how I easily accomplished it using AngularJS way back. It essentially built a data entry form in the main content area.

So, I had a library of my custom templates (input controls). Using a simple repeater on the data set, I stepped through the collection of objects and selected the template to use (by name) for each object. The current object was available as a model to that template as it was rendered.

  <div ng-repeat="question in vm.questions"> 
      <div ng-include="'/App/Components/' + question.questionType + '.html'">
  </div>

Say for a “questionType” of “singleLineText” the above angular HTML fragement would find the “singleLineText.html” template which would process the current “question” object.

The “singleLineText.html” template was essentially this:

<div class="singleLineText">
    <div class="panel panel-default">
        <div class="panel-heading clearfix">
            <h3 class="col-sm-10">{{question.text}}</h3>
        </div>
        <div class="row panel-body">
            <input name="tb{{question.questionId}}"
                    id="tb{{question.questionId}}"
                    ng-model="question.answer"
                    type="text" />
        </div>
    </div>
</div>
1 Like
2

Hi,

I think compose is what you are looking for. I’ve created a small example showing how it works: https://codesandbox.io/s/kw10xw295v.

I’ve added custom1 and custom2 as global resources in main.ts. When using webpack you have to change this to PLATFORM.moduleName as mentioned here

1 Like
3

Thank you stefan!

That approach seems exactly as simple as I was hoping for and I really appreciate you taking the time to mock that up for me.

1 Like
4

@JeffHare It’s very easy to handle the scenario described, as you can see from @stefan example. In the past, someone also asked questions about dynamic composition based on route and all kinds of dynamic composition that I cannot remember / find those Q&A combos. Here is an example of how you can create a dynamic CMS with Aurelia, where components view-models are selected based on route. https://codesandbox.io/s/ywyj60p9qj You can go very far beyond this, with a bit effort.

All it boils down to is how to make sure the bundler understand & know it has to include all those dynamic modules into the final bundle.

Good luck with your application.

5

Thank you! That looks interesting and very applicable to us. Lot to learn here. I’ll search for those Q&A posts.

1 Like
6

Nice to hear that. And for what it’s worth, here is an example of how to have remote view for a custom element, using XHR or fetch to retrieve template https://codesandbox.io/s/8ljmrq3vql

2 Likes
7

(digging up this thread)

This is an outstanding sandbox. Aurelia TypeScript Sandbox - CodeSandbox
Congratulations to @stefan

It should get much much more attention in Aurelia’s documentation.

The official help page for “compose” completely overlooks the critical feature illustrated by this sandbox: polymorphism on the model, and therefore on the view model, and therefore swappable components (which we can then be fed to a component that only has loose knowledge of what it’s meant to display). This pattern is absolutely central to modern web UIs, and paves the way for all sorts of equally critical patterns (e.g. inversion of control between the parent and the child).