Aurelia without classes

Help Requests
1

I know this was asked in GitHub a long time ago… I would like to know reasons why not to use Aurelia without classes. Would there be anything that breaks if functional approach is taken on building an app?

Thanks in advance :slight_smile:

2

Plain objects shouldn’t be a problem, at least not in v2 where there is a sort of functional api equivalent for every decorator (or rather, the decorators call the functional api’s).

So, for starters you could do this, which gives you a plain element without behavior:

Aurelia.app({
  host: document.querySelector('body'),
  component: CustomElement.define({
    name: 'app',
    template: 'Hello world',
  })
}).start();

Then you can pass in a class with behavior:

Aurelia.app({
  host: document.querySelector('body'),
  component: CustomElement.define({
    name: 'app',
    template: '<input value.bind>',
  }, class {
    value = 'Hello world'
  })
}).start();

Which is normally what you want, because the framework creates transient instances using the prototype from the class you pass in and storing metadata on its constructor. So that’s more memory efficient.

But if you like to save some keystokes and/or just prefer object literals, I don’t see why not:

Aurelia.app({
  host: document.querySelector('body'),
  component: CustomElement.define({
    name: 'app',
    template: '<input value.bind>',
  }, {
    value: 'Hello world'
  })
}).start();

It could be handy for dynamic data-driven apps. Probably less so for hand written apps because classes add structure and make things more testable.

3 Likes
3

@fkleuver Another thing we could do is extend the associated view mechanism that we’ve got in place for the new au-compose so that it can find views for objects that weren’t created via a class definition.

4

@EisenbergEffect Yeah, we’ll need to think about what exactly people are looking for. There are many ways to wrap / cleanup / combine existing apis into more pure functional looking ones. We could easily do that as a layer on top. It would be especially interesting for singleton view resources like value converters and binding behaviors which are otherwise singletons anyway.

I’m not sure how a custom element declared with the associate view mechanism would look like, though. Doesn’t that rely on conventions (webpack plugin etc)?