Is anyone useing aurelia-form,aurelia-api,aurelia-orm from spoonx?


I am wondering if anyone was using aurelia-form,aurelia-api,aurelia-orm from spoonx ?
Those libraries are no longer developed by spoonx.
Is anyone interested in developing on it and migrate to aurelia 2 ?

1 Like

I think all of those plugins are easy to port, if you are interested, maybe try one and post the questions you got a long the way here?

Okay thanks, i’ll try then.
Is there a new skeleton plugin for aurelia2 ? Which one can i use ?

1 Like

There’s not a skeleton plugin yet, as it’s relatively straightforward: everything is a registry in v2. A registry is an object with a property register, that is a function that take a container as first parameter. Like the following interface:

interface IRegistry {
  register(container: IContainer);

Some example hypothetical plugin scenarios:

  • export a single custom element: then you only need to export it, no need to do extra registration logic
  • export a group of custom elements/custom attributes: then you can do:
import { MyElement1 } from './my-element-1';
import { MyAttribute2 } from './my-element-1';

export const MyPlugin {
  register(container) {
    container.register(MyElement1, MyAttribute2);

Anoher example here

1 Like


Thanks for you help,
I have been able to create a basic plugin with this configuration (my first one with v2 !)
i’m moving on to migrate the spoonx plugins.


I have used aurelia-authentication:


Okay great, can you try porting the plugin to aurelia 2 ?


@bigopon i have been able to port 90% aurelia-form. But my brain hurt with the aurelia-view-manager. Can you help ?

1 Like

View URL in v1 is a dynamic runtime concept, based on our loader. In v2, we no longer employ a loader, so it will be different, and you no longer have/need this.

And nice progress :+1:

Thanks ! But how can I load dynamic custom view for my model ? Is it possible yet in v2 ?

1 Like

In v1, you specify a string to load your vm, and that string will be used as module path. Same principle in v2, just the way we load it will be a bit different, and we haven’t decided yet, but probably the loader abstraction won’t be there so there won’t be any view to manage. If we do introduce some loader, it would be just for the compose (will be named au-compose, but you can have alias) specifically.
Dynamically composing different view + view model is possible, though a bit hairy for now. Will update here.

1 Like

Hello @bigopon , is it yet possible to do dynamic custom view ?
good work !