akircher

An idea: Under the hood, it might be nice to have a "(non)strict-mode" binding behavior. That way in the docs you could describe `${example}` as the equivalent to `value.bind="example &...

I agree with @danfma, the only problem here is the combination of this feature with `if.bind`, `show.bind`, and ternary `? :` operations. I like the feature in general, but it...

In [ecma script discussions](https://esdiscuss.org/topic/optional-chaining-aka-existential-operator-null-propagation), there was a thought of adding an "existential operator" such as `deeply?.nested?.field` which would allow the user to opt into the behavior and be eventually/possibly consistent...

@jdanyow Yes, you are right the spec doesn't handle this specific need. My thought is just that I think a new type of syntax here might be more intuitive than...

Thanks to all. Sounds like a good plan. In the mean time, another workaround is using something like this in the template `value.bind="(nullOrObject || {}).property"`

This is a really great discussion. I love all the ideas. FWIW, my favorite is ``` Explicit class, explicitly aliased method @route('login') export class LoginRoute { @route('register') registerStuff() {} //...

Do we absolutely need the class level decorator. Couldn't it be implicit? From my intuition the decorators could be viewed as doing the same thing, one could just be considered...

@davismj I get what you are saying and you are correct. However, I do think its a mental model that almost all developers understand, its intuitive to reason about, and...

@fkleuver good point. I don't have a strong opinion here. Maybe accept user lifecycle options as parameter(s)? Some options for this would be: ``` //Boolean option @route('/login', true) //Navigation lifecycle...

Is there a point for a special syntax for named parameters? It seems that an object would work just fine without learning a whole new "router syntax". e.g., `book=id=1&language=sv` ->...