You have a great idea of something we should include in Aurelia 2 or something you believe we are missing? Let us know about them! Let’s open up some discussions.
some stuff from aurelia-plus seems handy.
Like the JSON and FILTER ValueConverters.
Also a convention or more documentation on how to manage huge forms and / or subforms would be great.
- A switch attribute behaving like several if attributes in a switch statement.
- Ability to reload the current route and retrigger the activate() statements (for data load)
We will add more stuff to the core, we just need to be careful and selective
Some things, no matter how commonly used, may be better left to users to implement their own specialized versions tailored to their needs.
There re so many potential ways to implement them. I’m concerned about an overload of feature requests we might get to support everyone’s use cases, while they are easy for end users to implement. In the framework we try to limit the problems we solve to things that are hard and/or tedious for users to do. Then it stays manageable for everyone.
That said, we may want to have a curated list of popular/commonly used resources. Should be easy for people to copy/paste and then tweak to their needs. @EisenbergEffect is this on the docs plan?
I’m guessing you mean a la enterprise, so including validation and i18n, possibly built dynamically based on server-side metadata etc?
I think a lot of people have ran into this sort of challenge and so have I. Dynamically generating (partial) components on the fly will be a lot easier in v2 with much more powerful APIs, but it probably wouldn’t hurt to have a bit of API surface that nicely aggregates it all together, specialized to creating forms.
It’s in the making
Why would manually invoking the lifecycle in question not be feasible? Could you be a bit more specific with a use case example?
The new docs will have a whole new section devoted to “examples”. We hope the community will contribute many copy/paste-able code snippets for all sorts of things.
Can we have something similar to https://www.webcomponents.org/ or https://bootsnipp.com/?
Heck, I might even start creating a community-maintained one, if you guys don’t want to create an official channel.
@khuongduybui Are you looking for something specific for out of the box elements? Or a specific presentation? We were just planning a huge examples library where people could search and find copy/paste code for all sorts of common things. Open to any user submissions, just like the rest of the docs.
@fkleuver From my experience, a dynamically generated form based on metadata does not work well apart from basic CRUD. In that as well there comes issues with integrating external UI components (a prime example is date picker). The issues that will come from that may vary wildly. Even if that is done, in real life apps, the (edit) forms will vary wildly based on context of the app or action.
My honest opinion is that might be a futile exercise. If need be, devs can always create such stuffs. I did that too using vCurrent’s
compose, and I am talking about enterprise level apps. The question is not about feasibility or ease of API, it rather the problems that follows later due to the generic design and lack of flexibility for customization. Another point on that is the custom elements created that way have a tendency to become highly ceremonial, for example a simple textbox might needs tons of (meta)data to correctly bind the data to underlying object.
Even if it is attempted to make a part of official vNext, it should not be a part of core framework, as that should a be separate framework in itself.
Would actually be nice if every example is accompanied by a codesandbox or whatever the current trend is. The point is to demonstrate that the examples still works, and with which precondition (read setup), otherwise the docs might end up with tons of outdated examples.
Keeping the core lean and things modular is good.
Yes, including validation like in Angular´s Reactive Forms would be great. But i was rather asking for help on how to to compose forms. Could be an API or just good examples.
Something like Control Value Accessor in Angular, for writing something similar to this.
I have the notion, that a lot could be done via content-projection - that one article came to my mind - but i dont know how.
Sorry, for making so many Angular references and comparisons. I am still thinking in Angular.
If there´s an “Aurelia Way” that does not need a lot of framework but rather more web-knowledge, i´d highly appreciate it, too!
Have a nice day!
Absolutely. Thank you for trying to keep things nice and clean!
Personally I would be happy to just have a blog post update on the vNext (version 2). The last version is quite dated
0.3 (Oct. 2018) and most people reading the blog have no clue what’s happening. I do see a lot more activities lately, in terms of PRs, on the GitHub repo though. But the fact is, that most people won’t go on GitHub to see the progress. Also, even if we go on GitHub and we check the Milestone list, it barely moved at all in the past few months, even if there was a lot of PRs merged.
So all in all, it would be really nice to have an update… is it happening this year? next year? What is done and what is missing? … and I really wish to see an answer in a blog post, not just here in Discourse.
Keep your users informed and they’ll be happy to know something is coming and stick with you… keep the silence and they might just go see what the neighbor has to offer.
Personally I would be happy to just have a blog post update on the vNext (version 2).
This please, it takes some significant effort to stay in the loop. Not that other frameworks are much better at this like with Vue 3.
I have an Au2 storybook up and running under my repo which you can use to start dabbling.
This doesn’t have convention support yet so everything is explicit, but here is some stackblitz for you as well. https://stackblitz.com/edit/typescript-au2?file=index.ts
We are planning an Aurelia 2 update post soon. I kept hoping for the next post to be our alpha announcement, but that’s still farther out than I hoped. So, I don’t think we can wait any longer on a general update post. In brief, Aurelia 2 is looking amazing. We just have a very high bar, even for an alpha release. So, it’s not quite ready yet. @ghiscoding Our build process now puts dev releases on NPM for every merge to master. So, we’ve been a bit lazy about getting official milestone releases out. We’ll see about getting 0.4.0 out soon though.
Also, I think it would be good to have on the home page a live example of how to use Aurelia Script for potential non-spa users.
That’s a great idea. @bigopon Could we put together an official code sandbox demonstrating Aurelia Script? Something suitable for the home page? I can update our page once we have the sandbox built. Speaking of, we also need something about that in our official docs, not just the readme for the script library.
How about a way to handle the common scenario of using 2 plugins that happen to register the same resource?
- Provide an option to apply a prefix upon registering the plugin
- Provide an option to exclude certain resources upon registering the plugin
- Or provide an API to de-register a resource after-the-fact
You should be happy to know that all of these are done already!
- Provide an option to apply a prefix upon registering the plugin (done)
- Provide an option to exclude certain resources upon registering the plugin (done)
- Or provide an API to de-register a resource after-the-fact (done)