Component Modularity

[roti]

Hi,

This is a question, not an issue. Regarding following statement:

This does, somewhat, negate the concept of component modularity; Quiescent's contention is that the benefit of top-down, value-based rendering exceeds that of truly modular components.

How can one achieve reuse if components are not modular (and therefore reusable)? I'm thinking of widgets, for example.

[Raynos]

You can create modular components if you have the correct data structures.

I do this pattern a lot

(q/defcomponent MyApp
  ""
  [state]
  (d/div (my-widget/render (:my-widget state))))

(def my-data {
  :my-widget (my-widget/state ...)
})

(q/render (MyApp my-data)
  (.getElementById js/document "root-element"))

Here a widget / component is split up into two functions, one that returns state and one that does rendering.

All you have to do is embed a components state on your state atom and then call the components rendering function with its state.

If you want to allow the component to mutate it's own state consider using something like om's cursors.

Another trick I do is I store channels on a components state and have the rendering logic put things into the channels and have the components state logic read from the channels and update it's own state.

If I ever want the parent to do something with the child component, I never mutate the child's state directly, instead I do

(my-widget/some-op (:my-widget state) ...)

[roti]

I understand what you suggest (I actually do it a little different: each widget state is accessible in the atom by its id, so I always pass the entire atom around), but isn't this a way to build modular components on top of Quiescent? I am trying to understand the opinion quoted above, especially how one can reuse parts without relying on modular components.

[Raynos]

@roti I think the confusion here is

truly modular components.

Most people think you need local state to achieve "truly modular". I think this more about not using local state then being modular.

[roti]

Could you elaborate on that? For example: how can I make a widget (e.g. datepicker) without local state? Or if widgets are not the answer, how can I organize my code, so I don't have to build the datepicker twice?

[Raynos]

@roti

You can implement the logic for a datepicker in one place. You can embed the state of a datepicker instance (one for each date picker you want) somewhere in your state atom.

You can then call render date picker with the instance state.

The important part is that you have modularity & encapsulation, the datepicker instance can have its own methods / update logic / event handling logic / etc. it's state is effectively owned by the datepicker.

However there is a difference between local state and state owned by one component. The latter is just by convenient rather then enforced by hiding state.