ISO: Moon Shots

[khuongduybui]

I’m indeed very happy!

[khuongduybui]

Next request, how about making it work with pnpm (without --shamefully-flatten)?
Basically the radical idea of pnpm is that a package should not rely on an inherited dependency (i.e. I need to use foo but I already depend on bar, which depends on foo, so I don’t explicitly state in my package.json that I also depend on foo). That behavior, now that I’m aware of it thanks to pnpm is quite dangerous because the author of bar may swap its dependency on foo with like-foo-but-better anytime and does not consider that a breaking change at all.

[fkleuver]

This is not the sort of thing the framework should be dealing with. AOT might come peeking around the corner to some degree, but ultimately if pnpm gives you a non-spec-conformant dependency tree in your node_modules folder then you’re going to get non-spec-conformant behavior. I’m not sure if we even want to try to fix that (if it’s even possible).

The whole idea behind au2 is to rely on specs and standards wherever possible and minimize customizations that deviate from that, especially in build tooling since we have so many scars from problems with that in v1 already
If you do have a concrete idea in mind, feel free to detail this in an issue in the aurelia v2 repo.

[khuongduybui]

The reason I even raised this issue up is because I genuinely believe that explicitly listing all DIRECT dependencies is a healthy thing to do. I couldn’t care less about how pnpm organize things (from Aurelia framework perspective).

[brandonseydel]

@khuongduybui a very verbose example showing things you asked for

import { Ripple } from './ripple/ripple';
import { Shape } from './shape/shape';
import { IRegistry, IContainer, Registration, DI } from '@aurelia/kernel';
import { Button } from './button/button';
import { CustomElement, Aurelia } from '@aurelia/runtime';
import { Card } from './card/card';
import { Theme } from './theme/theme';
import './scss/main.scss';
import { CardTitle } from './card/card-title';
import { Chip } from './chip/chip';
import { Icon } from './icon/icon';
import 'material-design-icons-iconfont';
import { Alert } from './alert/alert';
import { Badge } from './badge/badge';
import { Divider } from './divider/divider';
import { Avatar } from './avatar/avatar';


export class MaterialUI implements IRegistry, IMaterialUIConfig {
    public prefix: string = '';
    static config(config: (config: IMaterialUIConfig) => void) {
        const instance = new MaterialUI();
        config(instance);
        return instance;
    }

    register(container: IContainer): void {
        this.registerComponent(container, Button);
        this.registerComponent(container, Icon);
        this.registerComponent(container, Card);
        this.registerComponent(container, CardTitle);
        this.registerComponent(container, Shape);
        this.registerComponent(container, Divider);
        this.registerComponent(container, Badge);
        this.registerComponent(container, Ripple);
        this.registerComponent(container, Theme);
        this.registerComponent(container, Chip);
        this.registerComponent(container, Alert);
        this.registerComponent(container, Avatar);
    }

    registerComponent(container: IContainer, ...components: any) {
        for (const component of components) {
            const name = component.description ? component.description.name : component.name;
            container.register(component);
            if (!this.prefix) return;
            const alias = CustomElement.keyFrom(this.prefix + name);
            Registration.transient(alias, component).register(container);
        }
    }
}

export interface IMaterialUIConfig {
    /**
     * This is used to prefix all custom elements and attributes so one can name them whatever they want
     */
    prefix: string;
}

export const mdiClass = 'material-icons';

[brandonseydel]

done.

npm install pnpm -g
pnpx makes aurelia
--select pnpm for package manager
--cd to project name
pnpm start
--add tslib (this won't be the case in the future but pnpm requires)

[brandonseydel]

My moonshot is to get up and running with http://bit.dev. Working on that integration point next. After that I am cooking up aurelia-material 100% native.

[bigopon]

The doc in script repo has all necessary link for us to put it officially in our doc. One can simply start with any link there. We only need a community member to step up and make the dox

[brandonseydel]

*Update bit team is excited and is working with us to get first class support on bit.dev

[cberkley]

The moon shot I would like to see the most is better IntelliSense in views. The Aurelia VS Code plugin does a great job with Aurelia language things (ex: .one-way, two-way) but it doesn’t do auto-completion of class methods or variables.

I have no doubt this is harder to do without typescript because class properties are typically not defined. Getting this working even partially would go a long way toward providing the IntelliSense other frameworks that don’t separate their views and view-models get automatically.

Yes, you can override the convention and do it inline but I like to have my cake and eat it too .

I know there is already an issue for this on Github, but it appears to be inactive as of late 2017.

[brandonseydel]

Definitely on the list…We have some good contrib that are already getting us close.

feat(smartAutocomplete): Go to Definition

[cberkley]

That is awesome! Thanks, for the response.

[dannyweldon]

@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.

[bigopon]

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.

[dannyweldon]

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.

[bigopon]

Which is exactly why I mentioned that the doc could use a lot of help from community members

aurelia/documentation

[rluba]

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:

1. Resolving child routes by name, i.e., I’m at root.childState1 and want to navigate to root.childState2.subchild1. I’m not aware of any way to do this in Aurelia.

   root.childState1 has 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.

2. Relative routes: Building on the previous example, it’s often really useful to reference root.childState2.subchild1 relatively, eg., ^.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.

3. Route parameter types and default values: navigateToRoute has 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 moment or Date objects, but in URLs they have to be formatted, eg., as YYYY-MM-DD or 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 activate already gets validated, converted parameters.

   But there’s no way of doing the same for everyone who links to that state. Everyone who uses route-href or router.navigateToRoute has 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 root, child2 and subchild1
• look at all their parameter types
• convert the given params to 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.

[arnederuwe]

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.

Issue: [WIP] Compositional Router API [RFC]

[jwx]

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.

[khuongduybui]

Where are we with SSR by the way?