Road to V2

[WebReflection]

While latest API and logic is mature and battle-tested enough, there are few things that worked well but others that didn't shine in V1.

Following a list of things I'd like to improve for the next release:

• ES2015+ code. I'm happy about current hyperHTML compatibility and features detection capabilities, but the code is a little monolith written in old ES5, hence not too welcoming for contributors
• ES2015 modules. I'd like to split all internals in modules and utilities. This should give me the ability to produce a light version of hyperHTML that doesn't include method and wire adopt-ability
• there is already a 100% code covered viperHTML branch that produces layouts with hyper friendly comments in the right place. This would make hyperHTML adopt capability way easier, reaching attributes with ease but also making multiple placeholders discovery a no-brainer. Factoring out from main package adopt-ability would make hyperHTML lighter and hyperHTML.adopt accurate. Moreover, the current adopt logic is partially broken in core due unability to discover templates previously used.

This will be a big effort in terms of code refactoring, it will partially change/break current adoptability (an experimental feature not many are using so far anyway), but it will not change the API as we know it.

However, adopt will be not available by default (breaking change) and because of that I think V2 makes sense (as also previously suggested).

---

If you have anything in particular you'd like to see in a V2 please add a comment to this future-plan issue, thank you.

[asapach]

How about a build tool/optimizer (or babel plugin), along the lines of yo-yoify? Just an idea: is there some performance to be gained by modifying the AST to make run-time faster?

[WebReflection]

Actually I've just read what is yo-yoify about, basically it's exactly what huperHTML is out of the box.

So no, nothing like that is needed. It's already how the core works.

[asapach]

OK, another idea: is there a way to improve developer experience when using wire() with the same object, especially in a loop (https://viperhtml.js.org/hyperhtml/documentation/#api-1-2)? Should I always be using an id when iterating over elements? What if I mistakenly use the same id twice? What if I write one loop (without adding an id) and then my teammate creates another loop without realizing that we'll run into performance problems? Is it possible to catch these scenarios? Or better yet re-design the api to avoid them altogether.

[joshgillies]

tbh - I feel like wire() has been covered extensively, and it's actually not that difficult to understand once you've actually used hyperHTML for more than a day.

The api in my mind is sound, though potentially introducing environment based messaging could help direct users away from non-performant patterns eg.

if (env === 'development') {
  if (doingSomethingWeirdWithWire) {
    console.warn("You're potentially doing something weird with wire, have you considered...")
  }
}

This kind of messaging can be easily removed by uglify for production builds, but then again how much messaging is too much when there's already ample documentation covering wire().

---

Something I'd like to raise again for consideration is lifecycle hooks for hyper.Component. The quintessential example in my mind is:

class Timer extends hyper.Component {
  get defaultState() {
    return {
      secondsElapsed: 0
    }
  }
  tick () {
    this.setState({
      secondsElapsed: this.state.secondsElapsed + 1
    })
  }
  connectedCallback () {
    this.interval = setInterval(() => this.tick(), 1000)
  }
  disconnectedCallback () {
    clearInterval(this.interval)
  }
  render () {
    return this.html`
      <div>Seconds Elapsed: ${this.state.secondsElapsed}</div>
    `
  }
}

I wonder is there an approach where we can determine whether a component has been rendered and inserted into the DOM without having to resort to MutationObserver + polyfill.

Looking over the likes of patrick-steele-idem/morphdom you can see they have hooks for onBeforeNodeAdded, onNodeAdded, onBeforeNodeDiscarded, and onNodeDiscarded. Which they manage to implement without MutationObserver. I'd have to look closer at how they manage to pull it off, but if similar could be applied to hyper.Component I think that would help to bring hyper.Component inline with the expectations of developers coming from the React world.

[marcoscaceres]

Um, I still like AMD support (I know... but I'm using it with a legacy project)... otherwise, I need to put hyperHTML into the global scope, which makes me a bit sad.

[WebReflection]

@joshgillies

I feel like wire() has been covered extensively, and it's actually not that difficult to understand once you've actually used hyperHTML for more than a day.

Thank you.

is there an approach where we can determine whether a component has been rendered

as soon as you invoke this.render() the component is resolved and rendered

and inserted into the DOM

I could easily invoke a "connected" the first time it's rendered, but I cannot easily grant a "disconnected" without bloating the code and slowing it down per each splice operation.

On top of this, hyper components are compatible with the DOM right away. The only thing the "bind/render" does here is to invoke comp.render() if you pass a component instead of a node but technically you can have hyperHTML components that work out of the box on any other project simply explicitly invoking such .render() method.

Having hooks that work only when components are rendered inside hyperHTML is a functionality lock-in and I happily leave lit-html lock itself in its own classes and logic, keeping hyperHTML open to wider adoption outside its own domain.

without having to resort to MutationObserver + polyfill

I will check what/how they do that, but MutationObserver is the only way to go here, IMO. Remember: hyperHTML promotes the platform as much as it can.

@marcoscaceres

I still like AMD support

here I'm planning to move away from CommonJS and old syntax and go all-in ES2015 modules: AMD ain't gonna happen unless I export a file dedicated for that use case.

Would it work? Also ... if you had an ES2015 export could your bundler use it and wrap it as AMD or you need a file that's AMD out of the box?

Last, but not least, I also would like to see hyperHTML used in modern projects 😛

[marcoscaceres]

D'uh! Of course. I'll get it for free when I transpile! 🤠🥁👏

[WebReflection]

then you have already the .mjs version these days ... index.mjs and min.mjs are exporting as ES2015 module. Do these work already?

[asapach]

tbh - I feel like wire() has been covered extensively, and it's actually not that difficult to understand once you've actually used hyperHTML for more than a day.

IMHO, the fact that you can get used to it doesn't necessarily mean it's a good api.

[WebReflection]

I think he meant you should actually use hyperHTML before complaining about it.

Also happy to analize your proposal.

[joshgillies]

@asapach apologies of I came off as rude. My comment wasn't so much around the API itself but the reality that with some new concepts it actually takes building something in order for it to make sense.

A comparison could be made between wire() and closures/scope in JavaScript. In that you can do all the reading in the world but true understanding comes from actually using the technology before the concepts can really take hold.

For me the realization that wire() was a weakly held reference between an Object and a Document Fragment was the spark. But I feel as though calling it weak() would be even more confusing.

Again, if you have an alternative API in mind please share your thoughts. :)

[asapach]

OK, here's my problem with the wire API: why do I need to pass the id when I want to render different content based on the same object? Like wire(user, ':avatar') and wire(user, ':profile') in the docs. If I forget to do that, I'm shooting myself in the foot because it won't be able to track state.
A more contrived example is when I'm using this.html in a hyper.Component (which in turn uses wire(this) under the hood): I want to render content more than once, e.g. as a helper method (I don't say it's a good practice, but nevertheless):

render() {
  var snippet = this.renderSnippet();
  return this.html`Info: ${snippet}`;
}

renderSnippet() {
  return this.html`...`;
}

So here's my proposal: it should be possible to distinguish between wire(obj)`foo` and wire(obj)`bar` , since they use different TLs, so it should be clear that the intent of the developer is to use two different wires. Is it possible to cache wires based on TL rather than id?
Perhaps it could be a new/different API to avoid breaking existing functionality.

[joshgillies]

@asapach

Is it possible to cache wires based on TL rather than id?

Sure, but you still need a way to handle the following scenarios:

// svgs
wire(obj, 'svg')`...`

// lists
items.map((item, i) => wire(item, `:item-${i}`)`...`

// verbose equivalent of above
wire(obj)`<div>${[
  wire(obj, ':span-1')`<span>${'foo'}</span>`,
  wire(obj, ':span-2')`<span>${'bar'}</span>`
]}</div>`

For these cases (there may be others!) the only real way to handle them is by passing in an :id that you as the developer control. Personally I feel as though if there are cases where you're still required to manually assign an :id, we may as well make that the default for all cases.

Edit: #107 (comment)

[WebReflection]

@asapach the wire is a weak relation between an object and a DOM representation.

If I forget to do that, I'm shooting myself in the foot because it won't be able to track state.

It's the same of having a weakmap. If you wm.set(obj, value1) and then wm.set(obj, value2) you inevitably lose the obj <=> value1 relationship and JavaScript wouldn't warn you: it's your code, it's your choice.

The wire gives you the ability to address ids like in a WeakMap relationship such:

// wire(myobj, ':id1')
wm.get(myobj).id1;

// wire(myobj, ':id2')
wm.get(myobj).id2;

// wire(myobj, ':somethingElse')
wm.get(myobj).somethingElse;

Since it'd be inconvenient to write code in any other way, you'll find that wires give you out of the box a very simple mechanism to reuse an object to represent same TL, like @joshgillies showed already, or various TLs for various cases.

This is not going to change and I don't see any proposal that would make it more robust, any better, less confusing, or more flexible.