mercury
Version:
A truly modular frontend framework
83 lines (63 loc) • 2.27 kB
Markdown
A component in mercury is two things
- a "constructor" that takes some initialization arguments and
returns state
- a rendering function.
The `state` that is returned from a component is a
black box & a lens. You embed it into your "top level" state
atom at some key.
For example:
```js
var appState = mercury.struct({
loginState: LoginComponent(...)
})
```
You then update your "top level" rendering logic to call the
components rendering function with the state that you
"embedded" at some key.
For example:
```js
function appRender(state) {
return h('div', [
h('.header', [
h('.my-logo'),
LoginComponent.render(state.loginState)
])
])
}
```
A component also has events, this is similar to how you
pass channels into a component in om except it's slightly
less coupled.
The events a component jas might be something like
"login button pressed", i.e. a component is saying
"I have a login button but have no idea how to handle login,
please listen to my event and mutate the correct state somewhere".
For example:
```js
var loginComp = LoginComponent(...)
var appState = mercury.struct({
loginState: loginComp
})
LoginComponent.onLogin(loginComp, function (user) {
/* do something with user. probably ajax, maybe redirect */
})
```
Note that if you want to mutate the black box `state` of a
component you must not mutate it directly, a component
should expose a set of functions like `resetField(state)`
exactly like how evan has demonstrated.
For example:
```js
LoginComponent.renderLogOutForm(loginComp)
```
The advantage of this technique is that you need to know nothing
about how a component updates itself nor do you need to know
anything about any events a component might have.
Instead the component will internally broadcast any events
or do the correct mutation of it's own state.
Since the state it returns is a lens it will "mutate" the top
level state that the caller of the component has embedded the
component into thus triggering a redraw.
Note: this article is written based on my reply to the Elm
discuss thread about modularity, to see other techniques used
by Elm & om, read more at https://groups.google.com/forum/#!msg/elm-discuss/sv7DVJ47QkE/VhLr9_V-5E4J