That is awesome! Thanks, for the response.
@bigopon, and @EisenbergEffect I was thinking also of an an Aurelia Script example that uses progressive enhancement or whatever that shows how to enhance an existing server side application, similar to the example in the demo video on the vuejs home page, if possible. Such an example, if it can be done succinctly like that one, I believe would immediately appeal to php developers looking just to enhance an existing web page, but it depends on which audience you want to target.
Here is an example with aurelia script + enhance, for mvc apps. This is a clone of todo mvc framework comparison https://github.com/bigopon/todomvc/blob/d954e7e5a313a91dc5bfbf648e95481764db5628/examples/aurelia/index.html
Edit: it’s in es5 format, and is friendly to use on any browser. Just need Promise polyfill and that’s all.
Hey, @bigopon, that’s looking a lot more like what I was thinking of, thanks. That example may be too cluttered for a home page demo though (eg. comparing it to the todo demo that’s there already), but you’re on the right track, something that shows a php developer that “Hey, I can just add this code to my page and I get reactive binding. Cool.”
@EisenbergEffect, another thing that I would love to see is a return of your nice Aurelia introductory video on the home page like you used to have, or an updated version.
Which is exactly why I mentioned that the doc could use a lot of help from community members
Sorry I’m late to the party. Here’s my wish: I’d love to see a better/different router!
I really like Aurelia. I’ve migrated two medium-sized apps from AngularJS last year. Now we have four regularly updated Aurelia apps in production and I use it for all new projects.
Everything that Aurelia couldn’t do well out of the box I was able to fix with custom components, attributes, ValidationRenderers, Webpack plugins, etc. – except the router.
The old Angular-UI-Router does several things much better than current Aurelia – things that are very difficult to fix with custom code without rewriting large parts of the router:
Resolving child routes by name, i.e., I’m at
root.childState1and want to navigate to
root.childState2.subchild1. I’m not aware of any way to do this in Aurelia.
root.childState1has to know the full URL for
root.childState2.subchild1, all its parameters, where they have to go in the URL, and how to serialize them (see below). If any of these properties change, you’re hosed. And you have to manually construct that URL every time you want to link to that state.
This breaks state encapsulation and spreads knowledge about a state across all other states and templates that may want to link to that state. In a large, cross-linked application, this creates a nightmare of brittle references.
Relative routes: Building on the previous example, it’s often really useful to reference
^.childState2.subchild1. Aurelia has something similar (letting you specify just the name of a parent to navigate to it), but it’s way less powerful.
Route parameter types and default values:
navigateToRoutehas no concept of parameter conversion to/from the URL and simply converts all parameters to strings.
An example: We often have date, time or timestamp parameters for routes. They are usually
Dateobjects, but in URLs they have to be formatted, eg., as
HH:mm, depending on the use-case.
It’s fairly easy to automatically handle these URL-to-model case by adding a converter to the routing pipeline using
addAuthorizeStep. This central converter can ask the target state for its parameter types and default values and take care of the rest – so that
activatealready gets validated, converted parameters.
But there’s no way of doing the same for everyone who links to that state. Everyone who uses
router.navigateToRoutehas to know the target format and manually convert all parameters. Aurelia has no way to look up child states (see point 1), so there’s no way to get the target state’s parameter types to automatically convert them.
For comparison, in ancient AngularJS, I could simply say
$state.go('root.child2.subchild1', params) or
<a ui-sref="root.child2.subchild1(params)">. Angular-UI-Router would…
- look up the state definitions for
- look at all their parameter types
- convert the given
paramsto strings based on these parameter types, omit default values, etc. and create the URL accordingly (… and would throw a meaningful error if, eg., the state was not known or a required parameter was missing or malformed.)
The problem is that
configureRouter() (to add sub-states) is part of the state object itself – instead of being its own thing – so Aurelia would have to eagerly load and instantiate all states to build the full state tree.
If route configuration wasn’t part of the state object itself, Aurelia could include all sub-route configurations at startup (as Angular-UI-Router does) while leaving the sub-states and their templates, dependencies, etc. in separate chunks to be loaded when needed.
You might want to check the Router RFC of vNext. It seems you have a lot of hands-on experience with complex router scenario’s, therefore it would be very helpful if you check these scenario’s against the router rework for V2 and let the core team know if the new API has any shortcomings for the scenario’s you described above.
There will be a new router for Aurelia 2. So please, as @arnederuwe said, check out the various RFCs for it in the Aurelia 2 repo. And it’d also be great if you, and anyone else with more complex router scenarios, could join us on Discord for more direct communication.
Where are we with SSR by the way?
Also, on a related topic, where are we with NativeScript (6) plugability? (See [Request] Aurelia + Nativescript 5+)
we have been doing all our integration tests with JSDOM, bootstrapping/tearing an app up down easily, so it’s expected to be easy. Though I’d prefer to let either @fkleuver or @EisenbergEffect put some notes for this.
NS is the same, as the way we do it with PIXI, you can see a PIXI example in the vNext repo. NS is a natural fit for Aurelia, so once HTML story is done, it should be simple. Of course, any community member is welcomed to step up and accelerate the story, the core team would be more than happy to provide necessary help to make it happen earlier.
As @bigopon eluded, we run all our 50k+ tests in both the browser and in jsdom. The entirety of v2 is designed to be runnable in any JS environment. You can start a normal Aurelia app in NodeJS+JSDOM, render it in memory and send the response HTML to the client to get a static page. There’s not even a special package needed for SSR though we might add one for some syntactic sugar purposes. But it wouldn’t be a monkey patching thing like in v1.
We just need to implement the client-side enhance api to turn pre-rendered “dead” html “alive” again.
The v2 runtime is fully platform and environment-agnostic, so a nativescript renderer can be built on top of the runtime without any hacks or friction. But it does need to be implemented: someone with knowledge of NativeScript syntax would need to write the template compiler logic (traverse the markup tree, retrieve attributes etc, turn them into renderables).
With the compiler and rendering logic implemented, every core component and resource should work normally with NS the same way it would with HTML.
We have our hands full with other things though, so when it will be implemented all depends on demand and community help.
Thanks for the detailed status updates.
If I am to start building a Next / Nuxt equiv today, do you think it is:
- too late (you guys already have started something like that in private), or
- too soon (some key pieces are missing that are tricky for someone outside the core team to complement), or
- just right (in which case, can you point me to some code examples of rendering in NodeJS)?
We haven’t started working on it seriously yet.
@erik.lieben has been experimenting with static html generator in azure function https://github.com/eriklieben/serverless-september-poc/blob/master/HttpTrigger/run.ts so that should give you at least an idea of how the moving parts would come together.
Whether it’s “too soon” or “just right” - only one way to find out, I think
In principle it’s exactly the same code and APIs as you see in the regular examples, except you use the configuration from
@aurelia/jit-html-jsdom instead of
(I didn’t read this full thread) only the last post.
This is the blog post that belongs to the experiment https://dev.to/effectory/building-a-serverless-blog-site-on-azure-1phd. I still need to write a follow-up on the Aurelia parts, needed to rush this one out to make the deadline for the serverless september twitter action Hope to be able to make time for that in the next few weeks.
For now I’ve just loaded the regular bundle (the one you get if you generate a new project) using
@khuongduybui I am happy to answer any question to help you out, just let me know.
OK, I’ll get adventurous this October! Thanks for the encouragement
If I am to start building a Next / Nuxt equiv today
Can we use it as an Aurelia static site generator too? (Of course, any time in the future that was prepared.).
My hope would be to stay as close to the 11 tenets of sapper as possible, and while static generation is not a must-have, it’s generally in-scope.
My SSR venture is running into a wall, so in the meantime, what is the plan with
I think it’s an open question: Do we build our own component library? or do we just tell people to use such and such CSS framework or web components library (e.g. Ionic Web Components)?
Personally, I would like to have our own, but it’s a large project and historically we’ve had trouble getting enough people to work on it consistently to build up a big enough component offering and feature-set. It really deserves it’s own team of 4-5 regular contributors. I could seed the vNext aurelia-ux with a bunch of initial components that I’ve built on the side. But, I’m not sure just yet if we have the team members who could dedicate time to take it from my initial implementation and keep it moving forward. We might be in a better position to answer this question after the alpha, once a few more core things are in place, and with more eyes on the framework. I’m working on a few things on the side that could enable this as well, but it’s too early to say just yet.