aurelia vNext

[vegarringdal]

@fkleuver

feel free to create issues and ping us if you have specific questions. I have been looking at your v-grid as one of the first things I'd like to try and see working in vNext. It's a complex component that will be a very good migration test for us. I'll be more than happy to help you out with it. We might even want a proper grid component in this repository as a plugin package.

Figured I could just create a issue here so I dont spam that PR with questions

Just tried a simple test to see what classes/functions that was missing. Have these been renamed/replaced by something else ?

• ViewCompiler
• Container
• ViewResources
• processContent
• TargetInstruction
• processContent (@processContent)
• noView (@noView)
• ViewSlot

[fkleuver]

Thanks for listing these, helps us keep an eye on what we need to make sure keeps working.

• ViewCompiler Renamed to TemplateCompiler (inject ITemplateCompiler) (same concept, changed a little bit)

• Container Still Container (inject IContainer)

• ViewResources Renamed to IResourceDescriptions (same concept, changed a little bit)

• TargetInstruction Renamed to TargetedInstruction (same concept, changed a little bit)

• processContent (@processContent) The API is quite different wrt compilation (we may add backwards compatible adapter layer later on, if many people want it) but we are working towards something much better in fact. The interesting places for you to look are probably @bindingCommand (where you can define your own binding syntax as an extension to .bind etc) and @renderStrategy (probably closest thing to processContent, you'd tie this to a bindingCommand for a full custom processing flow)

• noView (@noView) Removed (this is essentially implied if you don't provide a templateOrNode / provide empty one)

• ViewSlot Currently removed, superseded by RenderLocation, may change again.

I can't go into too much detail simply because the API hasn't settled yet and there will be more changes to come. Let me know what you think about the new @bindingCommand / @renderStrategy decorators. They're still early ideas and we'll be building further on those

[vegarringdal]

@fkleuver

Thx for taking the time to tell me about these parts. 😄 Will be looking forward to looking more into it/see if I can get basic part up and running.

Never got around to go deep into how Aurelia worked, was hard when it was spread over so many repos. and no clear way to get up and running. Actually ended up making a mini framework my self for fun just to learn more. Simple link here, got many bad parts if you look at source, so dont get scared 😂 https://stackblitz.com/edit/mframejs-radio-select-new Learned a lot from failing, still do.

Its prb the main reason why Im really against plugins for bundlers, afraid they will scare me away like the loader did in the end. And make it hard to use with stackblitz and bundler like fusebox with all features. activated. But I could be wrong....

Is there any special way components get registered in au VNext to the correct app context I should know about ? The dependency system in Aurelia felt like it had a more hierarchy to it. A bit more advanced then I ever did with my simple hobby project 😄

processContent (@processContent) The API is quite different wrt compilation (we may add backwards compatible adapter layer later on, if many people want it) but we are working towards something much better in fact. The interesting places for you to look are probably @bindingCommand (where you can define your own binding syntax as an extension to .bind etc) and @renderStrategy (probably closest thing to processContent, you'd tie this to a bindingCommand for a full custom processing flow)

I just used this to get the html content of custom element I think i was the only way I managed to get it and clear it before aurleia stared using it. I could be totally wrong too, and maybe I could have done this in the constructor with the injected element ? was mosly thinking about grouping/columns locking that would work without being slugish/laggy on slow browsers like ie11

Here is a sample, maybe you can tell me if just doing this in the constructor code will work just as fine. https://github.com/aurelia-v-grid/vGrid/blob/dev-rebuild/src/aurelia-v-grid/grid/v-grid-footer.ts#L14-L28

[fkleuver]

Its prb the main reason why Im really against plugins for bundlers, afraid they will scare me away like the loader did in the end. And make it hard to use with stackblitz and bundler like fusebox with all features. activated. But I could be wrong....

The main difference between vCurrent and vNext is that in vCurrent everything was lazy loaded, causing a whole lot of async stuff to seep through the templating APIs. Now there's tree shaking and code splitting to deal with larger apps, and internally everything is synchronous by all means and purposes. When resources are available on app start, you don't need loaders anymore.

The bundler plugins are just there to help with the (fairly small) translation step that is needed to infer full configuration from a convention. They're not needed to make anything work. Just a convenience thing so users can write less code.

I just used this to get the html content of custom element

I'm pretty sure that would be redundant in vNext as it already implicitly happens like that. Not 100% sure. But look at this vNext code, it's doing something similar I believe: https://github.com/aurelia/aurelia/blob/master/examples/no-bundlers/jit-iife-inline/index.html

[vegarringdal]

The main difference between vCurrent and vNext is that in vCurrent everything was lazy loaded, causing a whole lot of async stuff to seep through the templating APIs. Now there's tree shaking and code splitting to deal with larger apps, and internally everything is synchronous by all means and purposes. When resources are available on app start, you don't need loaders anymore.

The bundler plugins are just there to help with the (fairly small) translation step that is needed to infer full configuration from a convention. They're not needed to make anything work. Just a convenience thing so users can write less code.

Yes, but please consider just having 1 plugin/tool that is bundler independent. Still afraid this just could escalate into a beast bringing more bad then good. :-)

I'm pretty sure that would be redundant in vNext as it already implicitly happens like that. Not 100% sure. But look at this vNext code, it's doing something similar I believe: https://github.com/aurelia/aurelia/blob/master/examples/no-bundlers/jit-iife-inline/index.html

Thx :-) Just need to try and more some time this week to look more into it :-)

[fkleuver]

Yes, but please consider just having 1 plugin/tool that is bundler independent. Still afraid this just could escalate into a beast bringing more bad then good. :-)

That 1 independent plugin/tool is the framework itself. As said before, no plugin is needed to make it work. Plugins we talk about will be very thin wrappers to just smoothen things out and utilize those particular tools to their maximum potential. The framework will not take a direct dependency on them, not even via an abstraction (like aurelia-loader). The framework doesn't even know about the plugins. It just gets the view metadata in different degree of pre-configuredness (if that's a word)

[vegarringdal]

@fkleuver

Great :-) Really want aurelia vNext to be very good and popular. Since I really do not like some of the alternatives :-) I just need to get some time to start experimenting :-)

[vegarringdal]

@fkleuver

Notice there is a "jsnext:main": "dist/index.es6.js", Any chance we can add ts:main too ? "ts:main": "distTS/index.ts", I know fusebox will use this, kinda great if you are debugging

[vegarringdal]

@fkleuver

update: {"version":3,"file":"aurelia.d.ts","sourceRoot":"","sources":["../src/aurelia.ts"]

looks like you are pointing sourcmaps to something that isnt added when npm install runs

[vegarringdal]

@fkleuver

ViewSlot Currently removed, superseded by RenderLocation, may change again.

Ive cleaned renamed a lot of this now in a own branch (vNext) but looks like these isnt anything called RenderLocation

Also simple question, how do we register a plugin ? :-)

Current progress on type errors (might be more hidden errors due to any type)

[vegarringdal]

@fkleuver

I have no idea if you have time to answer any of these, but here is a small update atleast. Maybe others can use/you guys can use information in the end for a migration guide :-)

Status:

• I kinda got the grid atleast triggering when adding element 😄

• Had to remove IResourceDescriptions (ViewResources) from inject, if I had it it just would not start.

• in my custom attributes/child customElements I could inject my main element class`VGrid``, if I do this now I break app, maybe this is changed or not added yet?

• bind event never triggered, but looks like bound is the new one here

  • Im missing the binding context and overrideContext here, the binding context gets a number, maybe Ican use that to something
  • closed I get to old binding context is in attaching event, looks like this is parent class

• bindable, this is changed or broken

Sample:

<v-grid-col col-field="bool"></v-grid-col>

If I have this my colField get variable "bool" @bindable({ attribute: 'col-field' }) private colField: string;

If I have this my somethingElse is undefined and variable col-field is added to class @bindable({ attribute: 'col-field' }) private somethingElse: string;

If I try and use .bind it does not get bound.

Bug or intended behavior?

---

Hope you get time and that any of this is useful at all If you will be to busy and I should wait before trying anymore then please tell me. Ive tried not to look to much into the au code, understood there was a lot of chnages and too early to use to much time there yes :-)
I might have gotten lost anyways 😂

[fkleuver]

Hey, appreciate the updates!

Notice there is a "jsnext:main": "dist/index.es6.js", Any chance we can add ts:main too ? "ts:main": "distTS/index.ts", I know fusebox will use this, kinda great if you are debugging

I wouldn't be sure how to test that though. Feel free to PR it - you probably know more about this than I do :)

looks like you are pointing sourcmaps to something that isnt added when npm install runs

Yeah that's correct and thanks for the reminder btw. We made some changes recently to use rollup and make it a single file output, but the sourcemaps broke. In any case we'll add src folder back in for the dev publish. That may be available in a couple hours or in a day depending on when the change gets merged.

but looks like these isnt anything called RenderLocation

It's IRenderLocation. We're currently not exporting most of the classes, but rather the interfaces (InterfaceSymbols).

Also simple question, how do we register a plugin ? :-)

Essentially you register stuff via DI. That's also how it works in vCurrent but it's wrapped differently. If you look at the BasicConfiguration class in packages/jit you can get an idea of you might plug stuff in. There are a few extra APIs one of which is registerTransformer, that allows you to override implementations. We do that with the ExpressionParser at the moment.

Had to remove IResourceDescriptions (ViewResources) from inject, if I had it it just would not start

It seems IResourceDescriptions isn't actually registered via DI, but ultimately it's just a wrapper around the container. If you need to request resources you can just inject IContainer and request them with .get(FooValueConverter) for instance. But if you for some reason need the resources after composition there might be a better way to accomplish what you're trying to do. What do you need to request?

in my custom attributes/child customElements I could inject my main element class`VGrid``, if I do this now I break app, maybe this is changed or not added yet?

Since we don't have AOT yet (which would take care of a lot of auto resolutions like this), you need to explicitly register all your resources via DI. e.g. new Aurelia().register(BasicConfiguration, <any>VGrid).

bind event never triggered, but looks like bound is the new one here Im missing the binding context and overrideContext here, the binding context gets a number, maybe Ican use that to something closed I get to old binding context is in attaching event, looks like this is parent class

Now $bind and $attach etc are placed on the component's prototype by the decorator and you don't need to touch those. The lifecycles are separated out in terms of responsibility. The internal $bind will call the bound(scope: IScope) on your component if you implemented it, and same for attached(). IScope has bindingContext and overrideContext. So bind -> bound and attach -> attached. The ones starting with the dollar are internal.

You don't need to manually update your bindings anymore if you implement bound Binding is almost completely synchronous, no more need for task-queue and all that. Changes to binding targets (that's DOM as well as nested bindings) are queued via a promise, so simply calling await Promise.resolve() is equivalent to flushing the task queue. Everything will be guaranteed to be up to date after that. In most cases you really don't need it though.

Ive tried not to look to much into the au code, understood there was a lot of chnages and too early to use to much time there yes :-)

Frankly I wasn't expecting you to dive right in like this, but I understand and share your enthusiasm :) If you as a plugin author want to fully utilize vNext's potential and start with it at this stage, the best advice I can give you is to actually try and start from scratch and incrementally add features as you learn the new APIs. There are some preliminary instructions on running the tests and debugging.

Regarding the source maps, if you just delete the .map files in your node_modules folder you can at least debug the es2018 outputs. I'll try to fix it soon

[vegarringdal]

@fkleuver

The best advice I can give you is to actually try and start from scratch and incrementally add features as you learn the new APIs.

Yes, Ill do that and make smaller issues on vgrid repo if I get into issues on something. Ill try and use stackblitz for samples too so its easy for you to test/debug I will tag them all with aurelia-vNext if you need to find them later. This issue is starting to get very long and all over the place 😂