Symlinks for keypaths - RFC

[evs-chris]

This is a port of #1722 to the lovely new Model replacement for viewmodel and friends. It basically allows you to create a link between two keypaths that makes them equivalent, which is particularly handy for master-detail type scenarios. For instance:

<ul>
  {{#each items}}
    <li on-click="link(@keypath, 'current')">{{.name}} {{.number}}</li>
  {{/each}}
</ul>
<button on-click="push('items', {})">Add</button>
<div>
  Name: <input value="{{ current.name }}" /><br/>
  Number: <input value="{{ current.number }}" />
</div>

This passes the tests that were added with #1722, but there probably need to be a few more. I would greatly appreciate any feedback on concept, construction, or further tests.

[evs-chris]

This now allows links in components to establish an implicit mapping to the source. The destination is always local to the component though, so it shouldn't make for any wackiness upstream unless the destination is mapped explicitly. Even then, it shouldn't cause any problems unless the link ends up as a cyclical reference with a mapping and multiple links.

As it stands, a link restores whatever it replaced when it is unlinked, so the link more or less shadows the old value. Would that be preferable to setting undefined in the linked model, as the old PR did? I think that, especially in the context of components with a destination mapping (for whatever reason), shadowing makes the most sense. But my sense has been known to not make sense, if that makes sense.

[heavyk]

that'd be especially useful for timelines ... what a great idea

[martypdx]

Nice :)

If I understand correctly, link is like set with two-way binding semantics. Conceptually mostly likely used for state vs data properties?

[evs-chris]

That's the goal. Basically, writing one side of the link is the same as writing the other, so yeah two way binding for arbitrary keypaths. It got a lot easier with models.

And yes, it's mostly a state thing to me. Primarily to make it easier to have a swappable piece of model in focus without resorting to getting weird with passing keypath strings to data functions and manually updateing.

[heavyk]

I have a usecase where this would be especially effective. (I think)

https://github.com/heavyk/affinaty/blob/develop/src/lib/decorators/markdown.js#L41-L45

what that decorator does, is it takes a keypath, and then transforms that content (it has markdown) into html. I then stick the innerHTML into the div (I know there's no sanity check... it's on the TODO)

but, here's the problem, when I use that in the comment list, it's inside of an each statement, so when I slice comments into the front, the keypath changes (which is why I can't use the observe in the decorator because the keypath changes out from underneath it).

https://github.com/heavyk/affinaty/blob/develop/src/partials/comment-list.html#L58

how could I do something where I can observe an item in an array, when that item can change its position in the array?

[evs-chris]

@heavyk I'm not sure I follow... are you editing a particular comment or just rendering them into a lit (that may get updated over the life of the view) from markdown? If it's the former, this would definitely help. You could link the current comment to a special path to edit it and everything would stay in sync. If it's the latter, I've had good results from just adding marked to my data and calling it with the data in a triple e.g. {{{ ~/libs.marked(.someMarkdownString) }}}. This also has the benefit of playing nicely with splice, though a decorator should too. If you pass the actual text ref to the decorator instead of the keypath, it will automatically get updates (well, re-rendered) as the model changes.

<div class="comment-body" decorator="markdown:{{.text}}">

[heavyk]

hi @evs-chris, it's both :)

the list does get updated and and I need to add editing to a particular comment (the ones that are yours).

three braces is an option I hadn't really thought of either. I elected to do it with a decorator for embedded videos. since there's no easy way to do it with css, they need their widths set to the parent element's width... (I know, it sounds like width: 100% but it's not that easy.)

but, your other idea of passing the ref directly, I think is my exact solution... gonna try it now. thanks!!

and I think I just got an idea on how to workaround the edits without links using the same concept... !!! :)

[Rich-Harris]

🤘