Sam Claus

I wrote up a duplicate of this issue (but left it because I think I described it much better) several months ago: #34713. It's a shame that with 3 of...

@rossyman Awesome implementation. Of course I can wish for the feature from the Angular team but in the meantime your decorator is the cleanest solution for sure.

For the record, [Svelte already has this feature](https://svelte.dev/repl/d0ad07f8631b4d9da291fdb1ad0d099e?version=3.31.2). A `@BooleanInput()` decorator or a `coerceBoolean` option would be _better_ than the current solution, but still not _good_. I have yet to...

> I've tried to do this on the component level itself and found a working solution: > > ```js > @Input() > set autohide(value: boolean | string) { > this.autohideBoolean...

@antony Yes, I understand that. The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under...

Okay, that is interesting. It makes sense since an action is just a function that could be passed as a value anywhere. So let's say I want to apply multiple...

@intelcentre I like the way you're putting it. @TylerRick I half-agree with what you're saying but I would also like the Svelte team to feature-gate very strictly because an influx...

@wickning1 Yes! That's what I'm saying! I believe the Svelte tutorial even suggests patterns like always adding a "klass" field exported as "class" to support adding extra classes to a...

Yeah I caught myself thinking about small one-off modal templates today and wondering if frameworks (not just Svelte) should support inline/local components. Then I stopped myself. 1. The "exportability" concept...

At first I was **strongly** in favor of the syntax matching the `{#await ...}` block where the default case is any markup located before the `{:case ...}` clauses. It's less...