Comments (18)
Reported to morphdom at patrick-steele-idem/morphdom#77
from nanohtml.
In itself it shouldn't be the worst the worst because the image is read out from cache each time, but I can imagine that you'd want to evade this scenario as much as possible regardless. You're indicating chrome freezes up for large images and that's definitely bad :(
An approach you can take is to memoize / wrap your function in a thunk. Fancy words for something that looks a bit like this:
var imgEl = null
function render (time) {
if (!imgEl) imgEl = html`<img src="${img}">`
return html`<div>
<h1>${time}</h1>
${imgEl}
</div>`
}
That way you no longer create a new request each time a render is passed. This should also work to optimize large sections of a tree, based on say changes in application state or other properties being passed.
I hope this was helpful. Cheers!
from nanohtml.
but I think it'd be nice to make the problem hidden from developers
Don't think that's possible - controlling re-renders is something that comes with the job I'm afraid. Be it through shouldComponentUpdate
in React, manual diffing using thunks or setting lifecycle hooks to load and unload data. I reckon the best we can do is document it and make it as transparent as possible - that way we keep control which is a great thing.
I'll add docs for this in choo, as I reckon you're right and this is definitely a framework-level concern too. Thanks!
from nanohtml.
Each contributor has different motivations but for me, I couldn't care less about competing with React or virtual-dom
. I use yo-yo
because it solves a very specific problem for me: I hate peer dependencies.
At work we use Ember, it's a massive app with over 400 components. It has literally taken a year and wading through a ton of merge conflicts to finally upgrade to 1.13
. The latest Ember is now 2.5
so who knows if our app will ever actually catch up.
This isn't Ember's fault, it's an inherit problem with peer dependencies when you maintain a large number of components. React and virtual-dom
have this issue too. One could argue the free upgrades we get from the framework makes it worth it. It's hard to actually know if all that time spent keeping up would have been better specifically improving our components instead.
Outside of work, I don't have time to keep up with a framework. So I use yo-yo
for everything. I can leave a project for a year and assuming the browser didn't break my code, it will still work with new modules I create.
I know this doesn't solve this particular issue but thought I'd share my own motivation behind the native DOM approach.
from nanohtml.
I think it would be great to hide this from developers. Obviously what @yoshuawuyts said about this coming with the territory is part of working with the real DOM, but also I think thats a cop-out answer when we haven't explored all the possibilities.
Two possible workarounds:
- wrap everything in a
<noscript>
tag before passing to morphdom, which disables all scripts as well as image loading, then have morphdom only operate on the inner tree (bypassing the tag) - rewrite the img url to be something like
morphdom-http://originalurl.com
and then have morphdom rewrite it when it gets inserted into the dom
from nanohtml.
@yoshuawuyts thank you! your solution works ✨ (proof: http://requirebin.com/?gist=0f7bb3b03959448e120f02d506f4cd7e)
However, made me think and try other solutions:
- React: http://esnextb.in/?gist=ec75c4fe3443dc16920a6d740415c090
- Virtual-DOM + hyperx + main-loop: http://requirebin.com/?gist=ecda5235da884da9335eb8029ccdcff9
Both work fine, no additional network requests. Which makes me wonder why the same won’t just work with bel
. virtual-dom
is smarter about creating new elements?
from nanohtml.
This is an interesting problem! Both React and virtual-dom have access to the previous value. So they can check if the values are the same and skip the operation. bel doesn't have access to the previous value so it can't check if it's the same as last time to ignore the operation. It only creates elements and relies on morphdom
or any other native DOM diffing library to handle the update.
For example we can't do the following when creating an element:
var previous = element.getAttribute(prop)
if (value !== previous) element.setAttribute(prop, value)
Because the element is always new and setting a src
on a img
element will initiate a network request.
AFAIK, appending to a document.createDocumentFragment()
will still initiate the network request too.
I wonder if we should handle certain properties that can initiate requests or side effect events specially somehow. Or if we'll have to use an element registry. Or just leave it up to the framework implementations to handle this?
from nanohtml.
The solution proposed by @yoshuawuyts is great, and seems like it would work well, but I think it'd be nice to make the problem hidden from developers. I'm not sure if that belongs in bel or a framework tho'.
Aside from src
, are there other attributes with side effects that happen immediately upon being set?
from nanohtml.
Don't think that's possible - controlling re-renders is something that comes with the job I'm afraid
But, from a user/developer perspective, virtual-dom
allows me to not think about this problem at all, meaning one less reason to use yo-yo
and bel
, even though I like them and appreciate the “real DOM instead of a virtual-dom” thing.
/cc @maxogden @substack, what do you think?
#tinylibrariesfatigue
from nanohtml.
I’m totally on board with your motivation. We went with yo-yo
in Uppy because we are building a file uploading library and wanted something simple and lightweight. And we’ve been generally happy with it, so thanks again. I plan to use it in my personal projects as well, once I get a hold of things.
from nanohtml.
@maxogden I'd be careful with tying bel
to morphdom
specifically; the more native DOM abstractions we use, the more generic and thus reusable the solution is. While i see a place for the solutions you're proposing, they wouldn't, for example, work with React's render loop or any other vdom
implementation.
Right now morphdom
seems to bench on par with react
- with virtual-dom
sitting at 2x the speed of that; and the fastest vdom implementation benching way above that. While morphdom
works great right now; I think we can all agree that it'd be great if we can finally get around to writing browser elements that outlast more than a single cycle of frameworks.
edit: that's not to say that I don't agree with you that it would be great if we could abstract this away from devs; we should def explore these options! What I'm trying to say is we should be cautious in using abstractions that diverge from the DOM, as relying on them might come back to bite us
from nanohtml.
@yoshuawuyts why wouldn't wrapping it in a <noscript>
work everywhere? is a 'native DOM' element. should work in any real/virtual DOM thing right?
from nanohtml.
BTW made an experiment to test the noscript theory and I can't get it to disable requests in chrome or FF so maybe that isn't even worth discussing further http://requirebin.com/?gist=8dc9eebaefdb1ca0d04684c7095619d6
from nanohtml.
why wouldn't wrapping it in a work everywhere? is a 'native DOM' element. should work in any real/virtual DOM thing right?
Oops; I interpreted it as though morphdom
would inject behavior surrounding this - which wouldn't be transparent. If morphdom
isn't the one adding this beahvior I'm def all 👍
from nanohtml.
Found another problem with the caching img element solution to prevent extra requests. For some reason when using pre-created element saved in a variable, entire element tree where that pre-created element is then used gets re-rendered in DOM.
Please see here: http://requirebin.com/?gist=0f7bb3b03959448e120f02d506f4cd7e. If you use inspector to compare behaviour of the two img elements — the first one gets thrown away by morphdom, preventing animations (the first animation can’t finish) and click events (which might fire in between those DOM changes). The second stays in place like it should.
from nanohtml.
Think this might be related to shama/on-load#10, which seems like an issue in morphdom
if I understood the thread well
from nanohtml.
What do you think of this solution by to the “src network requests” problem: patrick-steele-idem/morphdom#77 (comment)?
from nanohtml.
Waiting on patrick-steele-idem/morphdom#77 to be published; made a demo on how to create widgets with the isSameNode() API here: shama/on-load#10 (comment) (e.g. thunking!)
That patch should fix this issue 🎉
from nanohtml.
Related Issues (20)
- `default` alias not defined on server.js HOT 4
- onclick Event Handlers with nanohtml/raw HOT 1
- Support custom elements V1 extension of built-in elements
- Cannot find module 'estraverse' HOT 5
- browserify transform sourcemaps only working partially HOT 1
- SyntaxError: Octal escape sequences are not allowed in template strings
- The qualified name provided ('clipPath"') contains the invalid character '"'. HOT 1
- Support array for multiple roots?
- Svgs elements not created properly HOT 2
- Browserify transform does not work for code transpiled from Typescript HOT 1
- Custom DOM library support on Node.js (e.g. JSDOM) HOT 3
- Text node as a root ignores the following element
- Way to keep whitespaces intact? HOT 2
- Valueless attributes gets unexpected default value
- Unclosed tags insert unexpected text node
- Support for conditional attributes? HOT 6
- bundle.min.js in npm package doesn't add html to window object HOT 1
- autofocus on input HOT 2
- babel + rollup import error HOT 4
- Question on upgrading from [email protected] HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nanohtml.