Repository navigation
V2 Todos #140
Description
Activity
Transpilation Issues
- using
node.method(...spread)causes unnecessary Babel output, usenode.apply(node, spread)instead - using
typeof anythingcauses unnecessary Babel output if preset 2015 is used
- using
Ehat about babel-env?
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
typeofin the code, as example, Babel pollute the bundle with checks forSymbolbut I don't use a single symbol in the whole core so that's unnecessary churn.Reacted by Equinusocio and Textrasto whom might concern ... how about the
styleattribute 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.
Reacted by Emanuele Stoppa, Josh Gillies, Alexandre and Jordan Austin@WebReflection are you referring to something along the lines of:
hyper(document)`<div style=${{ backgroundColor: 'blue', border: 'red' }}>😎</div>`
@joshgillies yes, when an object, set properties right away (with the diff dance preact does too)
Reacted by Josh Gillies and Vaggelis PapadogiannakisI 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 tohyperHTML.define?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.
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
This issue helps me track changes needed to roll out hyperHTML V2.
Breaking Changes
hyperHTML.escape(useless since V0)hyperHTML.adopt(experimental, V1 too unpredictable, viperHTML has changes for it)document.importNodeinstead of trusting connect/attributeChanged events (Custom Elements life-cycle will be different and CE will be always upgraded)Refactoring
asbundlerollup to create index.js and be sure the resulting code doesn't throw in ES5 based enginesTesting / Maintenance
latest version of jsdomto code cover on the serverif latest jsdom workstest in isolation each CommonJS file or test index.js all at once.not needed, rollup is betterfor jsdom / nodejs sakeNice to have
hyperHTML.adopt(...)based on viperHTML changes and as separate bundle