-
Notifications
You must be signed in to change notification settings - Fork 595
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
discussion: Roadmap #152
Comments
Should choo include some way to write plugins and/or mixins? I'm thinking in other frameworks that allow to write some sort of custom extensions, like Vue does |
@YerkoPalma maybe? I wonder what kind of functionality you'd like to see that cannot be done with any of the existing / proposed hooks edit: or perhaps plugins could be like a way of registering multiple handlers on the hooks? -ghmmmm - basically becomes sugar then, but that might be kinda nice hey edit: hmmmmm, I'm quite liking this - would def mess with the internals butttt, could do stuff like: const devtools = require('choo-devtools')
const pull = require('choo-pull-stream')
const log = require('choo-log')
const choo = require('choo')
const app = choo()
app.use(devtools())
app.use(pull())
app.use(log())
const tree = app.start()
document.body.appendChild(tree) |
@yoshuawuyts haha yeah. I was thinking something like that. The plugins/addons/mixins or whatever you call it could allow to.
const chooFire = require('choo-fire')
// Wrap some firebase bindings and stuff
const app = choo()
app.use(chooFire)
// extend just the model
app.model({
state: {}
style: { // this is a new one
color: 'blue'
}
})
// add a new function
app.test(avaChoo)
// use flux as state manager
app.use(flux) So, what do you think? are those good use cases? Is this be too hard to achieve? |
@YerkoPalma hmm, so one of the things I like about Any customizations currently go through the Does that make sense? |
I totally miss the async wrapper idea, it sounds good 👍 Well, thats why I was asking, I think that plugins are needed when the library is like a blackbox, but whene is easy to hack the core I guess they are not useful. If I found myself with a real world use case I'll let you know. |
Just a friendly reminder |
@shama ah yeah, that's a solid point. What do you think of using I think to some extent peer dependencies can't be avoided, but I'm 100% with you that they should leak as little as possible into the application logic itself |
@yoshuawuyts My primary worry is plugins creating flavored elements; elements that only work with some choo plugin enabled. My secondary worry is the ecosystem creating choo plugins which could have been just regular modules accessible to everyone. Plugins by their nature are convenient and is why every framework implements an API for it. But my goal has been to try something different then what everyone else currently does. I want to see if a client side ecosystem can be built without peer deps. Just my 2 cents, but what if we tried to achieve the individual desired app behaviors (logger, devtools, etc) without a plugin system first. Then fallback to implementing a plugin API if the behavior is useful and deemed impossible without it? |
in case this helps anyone's thinking: the approach i'm taking with the very similar project |
I just added an unbound agenda item for investigating using webworkers to move as much logic off main-thread as possible. Right now there are no libraries that ship with an off-thread renderer implementation (rumor has it that angular2's webworker is mostly abandoned and might not make the ng2 cutoff). This is something I think we could really accomplish. We'd have to make some changes to morphdom to help us enable this -> the ability to extract a diff of the dom (which is actually provided via global/document in the web worker context) and then applying that dom patch to the real dom. Ideally I'll have some time in the future to start seeing how this could be added to morphdom. We might have bubble up some of this implementation from yo-yo, but this also means the entire TCBY ecosystem could hook into this feature! |
I really like the idea of using web workers in choo by default (or as an option). I'm just trying to develop something to make a pwa with choo, and in my research I found the pokedex.org app which is exactly what I was looking for. In the post about pokedex the author describes how he used web workers to manage the diff between the dom, so that app and specially the post, might be a good place to start looking at |
@YerkoPalma I have talked to @nolanlawson a few times re: web workers and choo (and he has said he's looking into choo a little!). I know there was some hacking done for the pokedex stuff in terms of the diffing; might be interesting to see if we could use the same serialization format for morphdom that he implemented for vdom. But it might be worthwhile to see if he has any suggestions of recommendations about this topic :) |
Yeah this is a super under-researched area, but I did implement vdom-serialized-patch as a solution for Best advice I can give is that you need to architect it such that the perf gains of multithreading are not outweighed by the cost of serializing and sending messages to the worker. I wrote about this a bit but to sum up:
Also this works best when basically the entire app lives inside the web worker because otherwise you are sending messages back and forth from the worker to the main thread constantly. There's also some research from Parashuram and from Chris Thoburn. |
You mean removing it from views? I have definitely used it and there are a few cases where that's the only way to accomplish something, particularly simulating lifecycle stuff. Would examples help? |
Tim, yeah definitely! Curious to the use cases you have (:
…On Sat, 7 Jan 2017, 15:42 Tim Wisniewski, ***@***.***> wrote:
remove prev from elements as nobody uses it anyway
You mean removing it from views? I have definitely used it and there are a
few cases where that's the only way to accomplish something, particularly
simulating lifecycle stuff. Would examples help?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#152 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACWleqipOUcKA70wYFaz0LyhPteTQmqJks5rP6RXgaJpZM4JI16J>
.
|
@yoshuawuyts You mean removing the |
Ah no, fair enough then - I thought literally nobody was using it so then
it wouldn't make sense. But if both of you are well thennnn, yup maybs we
should hold off on it (:
…On Sat, Jan 7, 2017 at 3:59 PM Arve Knudsen ***@***.***> wrote:
@yoshuawuyts <https://github.com/yoshuawuyts> You mean removing the prev
argument to render functions? I use it sometimes, for example to compute
diffs between previous and current state in order to update D3 graphs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#152 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACWlej-8pEFd7XJLoSCnx3J6dNjP3A74ks5rP6hBgaJpZM4JI16J>
.
|
lmao, we're diverging so much from this rn - current status https://github.com/yoshuawuyts/playground-nanoframework |
Pretty much everything on the roadmap is done. Closing because |
Sharing a bit of a higher level overview currently only in my brain so all
y'all know what's going on:
3.0 Use CPS
effects
and error / value propagationview
apiyo-yoify
applicable3.1 Performance
3.2 Plugins
3.2.1 fix path triggers
send(location:href)
call3.3 Custom async paradigms
wrap
hooks so alternative async implementations becomefirst-class citizens (e.g.
choo-pull
,choo-xstream
,choo-rxjs
, etc.)4.0 Routing
sheet-router
to handlehash
routes by default; would makehandling routes a complete no-brainer (it can be a bit tricky rn when using
both hashes and normal routes)
sheet-router
to no longer useroute()
4.1 Components
This is where we add one of the last large feature additions:
choo/component
.choo/component
based onnanocomponent
5.0 polish mode
I think at this point
choo
is quite stable. The syntax will probably notchange; we'll just keep making things smaller and faster.
nanomorph
on-load
fromchoo/html
now that it's part ofchoo/component
prev
from elements as nobody uses it anyway5.1 / 6.0 threads
effect
andreducer
execution using webworkersGoals not (yet) bound to roadmap
.forEach()
and.map()
calls and replacing themwith ES3 equivalents - speed and less array allocations ftw
action
calls and laythem out visually - would make debugging silky smooth
choo
is doing comparedto itself
The text was updated successfully, but these errors were encountered: