-
Notifications
You must be signed in to change notification settings - Fork 603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
components #486
Comments
Nice writeup |
I like the nanocomponent idea, but after reading this, it doen't sound like components are a part of choo. I mean, they can be used with choo, but they are not made for choo, also you could use (maybe) another component library with choo. var html = require('choo/html')
var choo = require('choo')
var components = require('choo-components')
var app = choo()
app.use(components(require('list-component'), require('form-component')))
app.route('/', mainView)
app.mount('body')
function mainView (state, emit) {
return html`
<body>
<h1>count is ${state.count}</h1>
<FormComponent path=${state.path}>
<List source=${state.data}></List>
</FormComponent>
</body>
`
} I don't know if that make sense, but thats the way it feels natural for me to use components. The registration method was the first one I came up with haha. |
Yeah that could totally work! It'd be heaps cool if people experimented
with all this and found patterns that work well - like you said: I don't
think we should tie components into choo - that way we keep core small and
allow people to innovate on top :D
…On Tue, May 9, 2017 at 2:08 PM Yerko Palma ***@***.***> wrote:
I like the nanocomponent idea, but after reading this, it doen't sound
like components are a part of choo. I mean, they *can* be used with choo,
but they are not *made for* choo, also you could use (maybe) another
component library with choo.
So, when I think about *choo components* I imagine a plugin or library
that extend nanocomponent and allow to use components in choo like this
var html = require('choo/html')var choo = require('choo')var components = require('choo-components')
var app = choo()app.use(components(require('list-component'), require('form-component')))app.route('/', mainView)app.mount('body')
function mainView (state, emit) {
return html` <body> <h1>count is ${state.count}</h1> <FormComponent path=${state.path}> <List source=${state.data}></List> </FormComponent> </body> `
}
I don't know if that make sense, but thats the way it feels natural for me
to use components. The registration method was the first one I came up with
haha.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#486 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACWleudrE3h00l6xOeCSIN1aAHKp6O4Yks5r4FdVgaJpZM4NJqrw>
.
|
Great summary. Has anyone played around with ways to initialise the components? You have to use |
I've only component-ized the entire list. I imagine the only way to do it with list items, is to track instances in an array, and manage their lifecycle in the array. |
Components are now availaible in choo, I guess is safe to close this, reopen otherwise. |
So @Karissa asked in https://github.com/datproject/datproject.org/issues/511 what the status is on a certain component, and I linked to like 5 different things. I feel I've got a pretty good grasp of the status of components in choo, but that information is not written down anywhere right now. So this is a tracking issue to figure out where our components are at.
Building components
When I first wrote about the ideas of choo v5, I also mentioned components. We didn't end up shipping components in the final release. This was because it turned out all the primitives for components can be built on top of choo, so by documenting the patterns needed, we can have them live as separate modules instead.
At their core, components are stateful DOM nodes that are not affected by the diffing algorithm. They manage their own lifecycle, and fire internal events when they're mounted, unmounted or receive new data. This makes them ideal to wrap stateful third party code, like the leaflet map framework.
In order to achieve stateful nodes, we must make sure that certain parts of the DOM tree are not diffed by
nanomorph
. We can do this by setting .isSameNode() on a node. This must be done conditionally, however, because at a first render we must pass a DOM tree. To detect when nodes are added and removed from the DOM we use on-load. Because wiring all these bits up together can be tricky, and prone to error, we created nanocomponent.nanocomponent
is the core of our component abstraction. It's just a convention turned into code. It exposes a prototypical API, which might prove to be a bit unwieldy if you're writing application code. So for applications we've created microcomponent. It has a whole bunch of conventions around state management, logging, tracing, and determining if elements should be updated. If you're curious how to write your ownnanocomponent
-based elements, I think themicrocomponent
API should give you a good idea of how to shape it (e.g. never expose a prototype API for application-level code).Core modules
nanomorph
requires to have stateful nodes, and uses on-load under the hood. It exposes a prototypical API. This is a module-level component; you should generally only use this if you're creating modules to put on npm and not in applications.nanocomponent
. It exposes an API that's quite similar to React's component API. But we also include tracing and logging, which makes it very debuggable. This is an application-level component; you should generally only use this if you're writing applications, and not use it to to create npm modules.microcomponent
. This is not sure yet, but I think there's a fair chance the two modules may converge in the future (or find a slightly different niche, too soon to tell)Issues
on-load
for stateful components, this might be an issueecosystem
nanocomponent
. Can be mostly modeled after base-elements/modal.And there's probably other elements that can be done: tabs, dropdown menus, slide-in panels, notification bubbles. The works. It'd be cool if people that are interested would start building those out too!
Wrapping up
And that's it - I think this captures the current state of components in choo. I hope it's been useful, and if you build something cool, have questions or want to help out on any of this - we'd love to hear from you! Cheers! ✨
The text was updated successfully, but these errors were encountered: