Element references

[jaandrle]

Hi,

I have made a very minimalistic implementation of this – see master...jaandrle:arrow-js:dev-ref. Its use is as straightforward as with other reactive expressions:

import { html, r } from '../dist/index.js';

const ref= r(null);
ref.$on("current", console.log);

html`
  <p ref="${()=> ref}">Hello World</p>
  <button @click="${()=> console.log(ref.current)}">Click</button>
`(document.body);

…but maybe it looks a little “code-twisting”.

I can add some syntax sugar, for example:

import { html, r } from '../dist/index.js';

const el= ref();
el.$on("current", console.log);

html`
  <p ref="${el}">Hello World</p>
  <button @click="${()=> console.log(el.current)}">Click</button>
`(document.body);

function ref(current= null){
  const ref= r({ current });
  const out= ()=> ref;
  out.$on= ref.$on;
  out.$off= ref.$off;
  Reflect.defineProperty(out, "current", {
    get(){ return ref.current; }
  });
  return out;
}

Or maybe do it completely differently? What do you think?

[irskep]

I second a request for this. One representative use case is calling inputElement.focus() after a modal dialog opens, to autofocus some input.

[stevelandeyasana]

(This is @irskep again, just poking at this during some work downtime. I know it's confusing.)

I took a crack at another minimalistic version of this idea: https://github.com/justin-schroeder/arrow-js/compare/master...stevelandeyasana:arrow-js:steve/refs-experiment?expand=1

I added special treatment for 'ref' attributes; attrs() will invoke the function immediately with the DOM node. It would probably be more appropriate to call this 'mounted', but it's just a proof of concept.

Here's the code I added to the 'tabs.js' example to demonstrate:

const tasksPanel = html`
  <div class="panel" ref="${(el) => console.log('Mounted Tasks panel on', el)}">
    <h4>Tasks Due</h4>
    <!-- ... -->
  </div>
`

The main problem with my code is it doesn't directly solve the use case I mentioned above, i.e. autofocusing an element when it appears. If you add an input element and say ref="${(el) => el.focus() }", nothing happens. I assume this is because the function is called before the node isn't in the document tree at the time attrs() is called. So you'd want to defer calling these functions until the whole update has been applied, which means collecting updates and then applying them all at once at the end of closeSubPartial (I think?).

@justin-schroeder if you think this is a reasonable approach I'd be happy to work on it some more, or stop if you don't agree with it.

[stevelandeyasana]

I went ahead and tried my idea of only calling the functions after the DOM nodes were present in the tree, which makes the autofocus-input example work: https://github.com/justin-schroeder/arrow-js/compare/master...stevelandeyasana:arrow-js:steve/refs-experiment-2?expand=1

As a user it feels nice to me (naming aside). I can't think of any needs I have that wouldn't be served by this or a similar API.

[justin-schroeder]

Good thoughts here @stevelandeyasana - I think a special attribute named "ref" is the right way to go yes. One distinction that is tricky though is knowing when the ref is mounted vs created. In attrs, as you point out, the Dom is available but not necessarily in the DOM, for some applications this doesn't matter, but if, say, I wanted to measure its position in the viewport I would need a later hook.

That said, part of what I want to do with arrow (and would love for the community to do as well) is fine "native" framework-like patterns in JavaScript. Currently we don't have lifecycles. Perhaps these lifecycle hooks can be accomplished in elegant (and terse) ways using some native JS.

That said, I think refs will make it in soon - I'm mid-stream on an api-compatible rewrite of arrow actually that should be dramatically faster and easier to read and will give us better places to hook in for these kids of mutations, although it sounds like you found the right ones already 👍

[jaandrle]

Regarding to 'ref', I'm not opposed in principle. Just considering other libraries/frameworks, they mostly work as I've shown. It would be more intuitive to use something like '$onmount' as attribute name and maybe not implement 'ref' at all, just indicate the usage via '$onmount' in the documentation.

[irskep]

Glad to hear about the rewrite. The code is pretty dense at the moment. I essentially did implement mount/unmount lifecycle hooks here, but the way it happens feels very ad hoc and the approach wouldn't scale to other types of lifecycle events.

I think I agree with @jaandrle about "refs" vs "onmount." I conflated the two concepts pretty badly in my proof of concept. Maybe the lifecycle hooks could be provided by html, but the refs implementation could be provided by reactive, building on the lifecycle hooks?

[justin-schroeder]

Lifecycles are definitely something to talk about (just opened a discussion about them #70). To some degree I'd like to avoid the "traditional" lifecycle events as they are reinforcing some mental models of React-like rendering that arrow is trying to escape. As I mention in that new post, there is definitely a place for "unmount", perhaps even one for "mount", although I'd love to find an elegant native solution.

ref to me is actually more interesting as it is a fast way to get access to specific DOM nodes within a chunk of HTML without needing to write querySelector calls (which are slow and inefficient) and Arrow actually has direct access to those nodes when they are created.

[irskep]

Another nice thing to have would be a way to directly insert DOM nodes into a template, which would reduce the code I'd need to write to integrate non-Arrow code with my Arrow templates.

const div = document.createElement("div"); // toy example; really I'm using CodeMirror's EditorView.dom
div.innerHTML = "blah blah";

const template = html`<div class="Editor" dom="${div}"></div>`

This could also mean you could have reactive DOM in templates:

const nodes = reactive({x: document.createElement('div')});

const template = html`<div class="Editor" dom="${() => nodes.div}"></div>`;
template(document.body);

nodes.x = document.createElement('span'); // replaces div created earlier

Just a thought. Obviously this isn't strictly necessary when refs exist, but it could be a natural extension of the philosophy of this library.