Currying Links ? #669

Activity

1. buschtoens commented on Jan 19, 2022

   

   buschtoens

   on Jan 19, 2022

   Last edited by buschtoens

   Owner

   More actions

   I think overall this is a great and useful suggestion. I can definitely see myself wanting to use such a feature in some situations. Thank you.

   But I fear the proposed mechanics won't work reliably:

   Issues with Models / Dynamic Segments

   Partial Application Base	Final Wrapper
   {{! route.hbs }} <MyPage @detailLink={{link "go-to-details"}} />	{{! components/my-page.hbs }} <Button @link={{link @detailLink this.model.id}}>...</Button>

   {{link "go-to-details"}} itself is missing a model, which is then provided one layer down by the wrapping {{link @detailLink this.model.id}} invocation.

   While the latter is a valid Link then, the former isn't, but there's no (convenient) way to tell them apart. If you were to access @detailLink.url, things will likely blow up, because RouterService#urlFor(...) is invoked with too few arguments.

   Additionally, there may be routes accepting more than one model, e.g. /user/:user_name/address/:address_slug. How would this support statically partially applying one model in the base invocation and dynamically applying the other model in the final wrapper invocation?

   Naïve Solution

   One option is to naïvely append models from left to right:

   {{#let (link "user.address" "buschtoens") as |baseLink|}}
     {{#let (link baseLink "home") as |finalLink|}}
       <a href={{finalLink.url}}>Home</a>
     {{/let}}
   
     {{#let (link baseLink "work") as |finalLink|}}
       <a href={{finalLink.url}}>Work</a>
     {{/let}}
   {{/let}}

   In this case :user_name is statically applied as "buschtoens" in the base invocation. The wrapping invocation then can dynamically apply :address_slug: "home" or "work" in this case.

   But what if you need :user_name to be dynamic instead? Since models are applied from left to right, that won't work. For routes taking even more models, it gets even worse.

   Issues with Query Params

   For query params it's not as bad, because they are named instead of positional. However, that introduces a second problem: Wrapping invocations may unintentionally override query params that were set in the base invocation. This can lead to bugs. But in a different scenario, this behavior may be desirable.

   Intermittent Solution

   I think we need to bikeshed this a bit more and consider various use cases.

   For the time being, you could easily achieve this with a custom (inline) helper. It even gives you maximum control over how arguments are applied.

   import { helper } from '@ember/helper';
   import { inject as service, Registry as Services } from '@ember/service';
   import Component  from '@glimmer/component';
   
   export default class MyComponent extends Component {
     @service('link-manager')
     private declare linkManager: Services['link-manager'];
   
     readonly buildDetailsLink = helper((id: string) => this.createUILink({
       route: 'go-to-details',
       models: [id]
     });
   }

   <MyPage @detailsLink={{this.buildDetailsLink}} />

   <a href={{get (@detailsLink this.model.id) "url"}}>...</a>

   Using ember-functions-as-helper-polyfill the component class would become a bit more concise:

   import { inject as service, Registry as Services } from '@ember/service';
   import Component  from '@glimmer/component';
   
   export default class MyComponent extends Component {
     @service('link-manager')
     private declare linkManager: Services['link-manager'];
   
     buildDetailsLink(id: string) {
       return this.createUILink({
         route: 'go-to-details',
         models: [id]
       });
     }
   }

   Potential ember-link Support

   Considering that Ember is evolving towards easier & convenient interoperation of templates & JS, this pattern may turn out to be preferable anyway.

   We can trim down this code even further with a utility function. We might even add a static method on Link / UILink, like this:

   import Component  from '@glimmer/component';
   import { UILink } from 'ember-link';
   
   export default class MyComponent extends Component {
     readonly buildDetailsLink = (id: string) => UILink.for(this, {
       route: 'go-to-details',
       models: [id]
     });
   }

   class Link {
     // ...
   
     constructor(linkManager: LinkManagerService, params: LinkParams) {
       // ...
     }
   
     static for(
       ownedObject: object,
       linkParams: LinkParams
     ): this {
       const owner = getOwner(ownedObject);
       const linkManager = owner.lookup('service:link-manager');
       return new this(linkManager, linkParams);
     }
   }

   👍React with 👍1Reacted by Thomas Gossmann

   ❤️React with ❤️1Reacted by Thomas Gossmann

   🚀React with 🚀1Reacted by Thomas Gossmann
2. gossi commented on Jan 22, 2022

   

   gossi

   on Jan 22, 2022

   CollaboratorAuthor

   More actions

   Aaaah, thanks for highlighting that currying cannot always work. It was just my initial case in which it worked.

   However, really like the idea for the factory method (esp. with ember-functions-as-helper-polyfill).

   Let's do this 💪