okdistribute / hyperdrive-ui

Render a hyperdrive in the browser.
http://karissa.github.io/hyperdrive-ui/
40 stars 4 forks source link

[PROPOSAL] use components+yo for hyperdrive-ui #51

Closed laurengarcia closed 8 years ago

laurengarcia commented 8 years ago

maybe we can talk about this on our upcoming call:

am proposing that we start breaking hyperdrive-ui into components. it's going to get unwieldy fast if left as it is, and i have gotten used to and really love component-based architectures. i'm new to yo and maybe there are some established patterns already out there. i kind of like what is below but am open to suggestions, improvements and total departures from this of course.

if you take a look at components/hyperdrive-size/index.js, the crux of what is proposed here is that

Curious your thoughts. We should probably look at getting choo into the mix, but also realize we need to just hack some demos real quick too.

laurengarcia commented 8 years ago

@karissa's feedback: "some components -- those that update their internal state like yo-fs, will need to have a class prototype to keep their widget around".

Gotcha. Updating this. Also had more ideas around this. More to come.

okdistribute commented 8 years ago

also i think that the getSize one in particular might just need to be a function on hyperdrive instead of its own ui component.

laurengarcia commented 8 years ago

@karissa was trying to use archive size as a starting point for reasoning about components since it is relatively compact and can be reasoned about easily. honestly IMO everything should be a component. archive size has its own state that needs updating at particular points (in the upload() case in particular). where does it live otherwise? i don't like the idea of things just floating amorphously in one monocontroller.

laurengarcia commented 8 years ago

@karissa also, archive.getSize() is definitely a thing that should exist. the logic of getSize() is not the rationale for it being a component, tho. the rationale is that it is a stateful thing with its own yo template and (will have) its own associated styles.

okdistribute commented 8 years ago

okay. i was thinking about components at a higher level, like 'hyperdrive folder viewer' or 'comment thread' but i see what you're saying

laurengarcia commented 8 years ago

just capturing irc comments here:

freeman-lab> eljee juliangruber: i've been playing with choo and really like it freeman-lab> it wraps something called 'send-action' that may make minidux unneccessary eljee> freeman-lab does send-action get sent by some master state? freeman-lab> eljee: so both send-action and minidux/redux have a master state, in minidux there's just one state, with send-action + choo you can have a few scoped states eljee> i guess that's what i am looking for. i have built apps with components that each have their own state, but then when you need components to be aware of each other you end up needing to send events through a master state anyway, so why not start with a master state is my reasoning freeman-lab> and then you write functions (reducers) that take the current state and an action and update the state freeman-lab> and you use a global 'dispatch' or 'send' function to trigger those reducers freeman-lab> which updates the master state, and (usually) triggers a DOM update

laurengarcia commented 8 years ago

sorry about closing this, its a side-effect of switching this to another branch besides laurengarcia:master. updates to this will be on laurengarcia:componentify.