yeah, at the moment, getter/setter. (i'm not sure if ngOnChanges works with setInput, which is the underneath API that sets these Route Input binding). Later with Signal Inputs, it is much easier to react to Input changes
Yes it does. But you have to enable component input bindings a bit different. In the RouterModule.forRoot call you have to pass in the option bindToComponentInputs: true
I am still salty they didn't go with a new decorator like @RouterInput or whatever. A normal @Input just screams problems to me. Finding usages will be impossible and when people delete the input (because they didn't find any usage) they will be hit with a runtime error...
Yeah I'm not sure about why not a decorator. I think they're trying as best as they can do not use decorators... but yeah there's something magical to this. You basically have no idea if the input is from component props, route or provider. But then again it's a nice feature tbh. Having to inject Router was really a pain in the ass. I use Ngrx store for these things anyway, so for me the store exposes route params via observables.
I was also thinking about this and came up with the idea of aliasing. I discussed this on Twitter. twitter.com/kreuzercode/status/1653027828114378753?s=20
I initially thought that it was good to alias, but then I received a component that made me think differently. From a component point of view, it's not important where the inputs are coming from - it can be a route or from HTML. It doesn't matter for the component.
@@nivekDev yeah it doesn't matter for the component, but for the developer it kinda does. As i said not finding usages is a very bad DX and will lead to a lot of errors. Creating aliases (or leaving comments) is too developer dependant, so i don't like that approach
I think it's not that important, because it's very likely that this component will never be used inside a template, so there will be no usage of the input in the traditional way, and it will be very easy to spot the configuration.
Excellent video to keep us up to date 😎
Thank You
great quick tip video, however, how do you react to changes to the route input parameter. use the long form get/set for input property?
yeah, at the moment, getter/setter. (i'm not sure if ngOnChanges works with setInput, which is the underneath API that sets these Route Input binding). Later with Signal Inputs, it is much easier to react to Input changes
Yes, you can use a setter and getter.
Does it work for ngModule based component?
Ha ha good question ! I shall try this, since I'm sure ngModules have still some lifespan ahead 🙂
Yes it does. But you have to enable component input bindings a bit different. In the RouterModule.forRoot call you have to pass in the option bindToComponentInputs: true
@@nivekDev Thanks for the response.
I am still salty they didn't go with a new decorator like @RouterInput or whatever. A normal @Input just screams problems to me. Finding usages will be impossible and when people delete the input (because they didn't find any usage) they will be hit with a runtime error...
Yeah I'm not sure about why not a decorator. I think they're trying as best as they can do not use decorators... but yeah there's something magical to this. You basically have no idea if the input is from component props, route or provider. But then again it's a nice feature tbh. Having to inject Router was really a pain in the ass. I use Ngrx store for these things anyway, so for me the store exposes route params via observables.
I was also thinking about this and came up with the idea of aliasing. I discussed this on Twitter. twitter.com/kreuzercode/status/1653027828114378753?s=20
I initially thought that it was good to alias, but then I received a component that made me think differently. From a component point of view, it's not important where the inputs are coming from - it can be a route or from HTML. It doesn't matter for the component.
@@nivekDev yeah it doesn't matter for the component, but for the developer it kinda does. As i said not finding usages is a very bad DX and will lead to a lot of errors. Creating aliases (or leaving comments) is too developer dependant, so i don't like that approach
I think it's not that important, because it's very likely that this component will never be used inside a template, so there will be no usage of the input in the traditional way, and it will be very easy to spot the configuration.