Hyperhtml: V2 Todos

[WebReflection]

This issue helps me track changes needed to roll out hyperHTML V2.

Breaking Changes

• [x] remove hyperHTML.escape (useless since V0)
• [x] remove hyperHTML.adopt (experimental, V1 too unpredictable, viperHTML has changes for it)
• [x] use document.importNode instead of trusting connect/attributeChanged events (Custom Elements life-cycle will be different and CE will be always upgraded)

Refactoring

• [x] use 100% standard ECMAScript 2015 code as ESM
• [x] avoid transpilation bloat/interference/feature detection issues (use a defined set of transpiling rules instead of the whole 2015 preset)
• [x] use ascjs to create CommonJS version of the module
• [x] use ~asbundle~ rollup to create index.js and be sure the resulting code doesn't throw in ES5 based engines
• [x] use uglify-js 2 to create min.js and be sure the resulting code doesn't throw in ES5 based engines
• [x] split dependencies in folders avoiding circular dependencies
• [x] branch out less capable browsers and keep the fast path on modern browsers (too many if/else inside code, just create different callbacks for better/easier code coverage too)
• [x] for custom elements sake, remove hyper HTML attributes before importing and put them back after, avoiding misleading callbacks. Solve all attributes before connecting the node and never after.

Testing / Maintenance

• [x] try to use basicHTML ~latest version of jsdom~ to code cover on the server
• [x] make greenkeeper happy ~if latest jsdom works~
• [x] ~test in isolation each CommonJS file or test index.js all at once.~ not needed, rollup is better
• [x] aim to the glorious 100% code coverage, trying to avoid ignores ~for jsdom / nodejs sake~

Nice to have

• [x] ~hyperHTML.adopt(...) based on viperHTML changes and as separate bundle~ will be out in another release

[WebReflection]

Transpilation Issues

• using node.method(...spread) causes unnecessary Babel output, use node.apply(node, spread) instead
• using typeof anything causes unnecessary Babel output if preset 2015 is used

[equinusocio]

Ehat about babel-env?

[WebReflection]

unnecessary, hyperHTML is easily compatible with IE9+ and Android 2+.

Target browsers will be preserved since it's a no brainer, the isue with Babel is that I want control the output and drop all the unnecessary churn.

If I use a single typeof in the code, as example, Babel pollute the bundle with checks for Symbol but I don't use a single symbol in the whole core so that's unnecessary churn.

[WebReflection]

to whom might concern ... how about the style attribute is handled in a special way?

I think the React/Preact solution is reasonable and I'm thinking about bringing it in V2.

I don't encourage the usage of inline styles, but for those that changes frequently it feels silly to not improve developer experience there.

[joshgillies]

@WebReflection are you referring to something along the lines of:

hyper(document)`<div style=${{ backgroundColor: 'blue', border: 'red' }}>😎</div>`

[WebReflection]

@joshgillies yes, when an object, set properties right away (with the diff dance preact does too)

[sourcegr]

I believe it is a nice to have addition, but I am not sure if it should land on the core.
Isn't there a way to add this feature (and possibly others) as a plugin or something or with a mechanism similar to hyperHTML.define?

[WebReflection]

There are only 3 kind of attributes:

• events
• special/inherited
• regular

hyperHTML already handles all cases so there’s no room for extension.

Within the special case though, there is the style, which has been universally created via object literals and it’s some sort of de-facto standard.

Differently from nodes , where the content might constantly change, attributes behavior is defined as one-off operation so there’s no way to change/define new behaviors later on.

This constrain grants both extreme performance in attributes handling and consistent behavior with custom elements and built ins.

I don’t think it’d be wise to lose all of that for a use case that is very rare while passing objects has been widely used already. After all, if you want to transform an attribute inline you can do so already using a callback within the interpolation.

[WebReflection]

P.S. master has V2 already. There are tons of subdole changes but beside what’s been dropped it should be fully backward compatible, faster in some case, more reliable overall.

If any of you could test it and confirm it works out of the box, that’d be ace!

Thanks