Comments (7)
It's only necessary when you use the OO interface and override El.prototype.render
. If you go functional, it's not necessary. I'd favor removing the prototype override in a major version bump and requiring everyone to pass in vtree-returning functions.
from base-element.
Hmh, it's kind of confusing to have two interfaces. Maybe it should be split up in two modules / converge into a single interface? Adding es6
classes to the mix complicates things even more, interface-wise.
edit: I realize that this is a bit off the point I raised in my initial point, but it might be a way to further reduce the interface surface of this module.
edit2: @bendrucker thanks for pointing it out; didn't realize it was that way ^^
from base-element.
I think it's confusing to let people totally break the render method and then basically offer a way to easily call the original:
Lines 27 to 32 in 981433c
I think it's reasonable to:
- Expect people to implement a particular method on the prototype that's otherwise a noop
- Allow people to monkey patch things that they want to change
afterRender
is a weird mix of the two where you're monkey patching a method that takes a vtree and renders it and being encouraged to instead return a vtree and wrap it in an afterRender
call.
from base-element.
The reason it was done that way is so one could deeply nest elements and only the top level element calling render
would do the diffing. I'm totally open to removing afterRender
if we're still able to detect the top of the render stack to do the diffing there. I just couldn't figure out a way without requiring afterRender
to be called by the user's implementation.
from base-element.
Thought about this some more and it's still bugging me as a source of confusion. The functional style is presented as an alternative, but it's not really the same. el.render(callback)
will always create a DOM element. You'd need to do el.render = render
.
I don't think I actually understand how afterRender
is supposed to work. When you this.__BaseElementSig__
not be truthy?
Line 28 in 981433c
from base-element.
this.hasOwnProperty('__BaseElementSig__')
will be false whenever it is on a prototype.
The primary thing base-element
solves is it allows me to create a bunch of modules that can inherit each other. Each of those modules will never need to be upgraded because of a version bump on a framework or another renderer library. They all can run standalone or together, regardless of the version of base-element
or any other library.
An example is:
- I create an
class Input {}
element. It only validates the value as!empty
. - Later I
class PasswordInput extends Input {}
which inherits the behavior, hides the input and validatesvalue.length >= 8
. - Much later I
class ShowPasswordInput extends PasswordInput {}
which inherits the behavior but adds a "✅ Show" to toggle whether to hide/show the password value.
Each of these elements call this.afterRender(vtree)
in their render()
implementation.
If I do let input = new ShowPasswordInput(); input.render()
, the render()
call will traverse down the prototypes building up my virtual dom tree. When this.afterRender()
is called on each prototype, it will not render, only return the tree.
It is only when it hits the top level render()
call or the element that hasOwnProperty('__BaseElementSig__')
does it do the virtual dom diffing and renders the entire tree.
Without this, each library would need to do the diffing/rendering on every render
call and would very likely cause a perf hit implementing this nested architecture. It also makes each element in the nested architecture remain standalone, without needing a separate API or library.
The functional API bypasses this architecture as it isn't aware of where it lives in the render chain (and I don't know a good solution to make it work there). So it runs with every element diffing/rendering.
Which means architecturally, the class API is preferred. The functional API is really convenient to generate elements on the app level or within modules that need or can render more often.
from base-element.
Right, totally didn't think of inheriting prototype.render and that elements would no longer have an own property from the constructor.
from base-element.
Related Issues (11)
- server side rendering
- Add function removeEventListener HOT 2
- Combine the server / client test script
- extract style > css / css examples HOT 5
- Document setTimeout delay rationale HOT 3
- replaceChild vs appendChild HOT 5
- Security HOT 2
- .toString()? HOT 2
- Rename `.on()`? HOT 7
- Default __appendTo__ to false instead of document.body 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 base-element.