Modules in V2

[zaceno]

💁‍♂ Check out the current proposal here.

---

Consider this minimal example of a modular Elm app (copied from here):

Button.elm

module Button exposing (Model, Msg(..), init, update, view)

import Html exposing (Html, button, div, h1, text)
import Html.Events exposing (onClick)



-- MODEL


type alias Model =
    Int


init : Model
init =
    0



-- UPDATE


type Msg
    = Increment
    | Decrement


update : Msg -> Model -> Model
update msg model =
    case Debug.log "Button.update msg: " msg of
        Increment ->
            model + 1

        Decrement ->
            model - 1


view : Model -> Html Msg
view model =
    div []
        [ button [ onClick Decrement ] [ text "-" ]
        , div [] [ text (String.fromInt model) ]
        , button [ onClick Increment ] [ text "+" ]
        ]

Main.elm

type alias Model =
    { button : Button.Model }


init : Model
init =
    { button = Button.init
    }



-- UPDATE


type Msg
    = ButtonMsg Button.Msg


update : Msg -> Model -> Model
update msg model =
    case Debug.log "update msg" msg of
        ButtonMsg buttonMsg ->
            { model | button = Button.update buttonMsg model.button }



-- VIEW


view : Model -> Html Msg
view model =
    div []
        [ h1 [] [ text "elm button example" ]
        , map ButtonMsg (Button.view model.button)
        ]

Notice two things:

A) Increment and Decrement are completely unaware of the shape of the global app state. Their definitions are completely self contained.

B) Main.elm never once explicitly references Increment or Decrement.

As far as I've been able to tell, this is not possible to achieve using Hyperapp 2. You can have A or B but not both. This has frightening implications for large scale apps.

I would like to see a convention, add-on library or core change -- or some combination of all three -- which enabled us to replicate the example above in Hyperapp v2.

That essentially means being able to use a module which defines its actions in a self-contained, app-agnostic way, without being required to export them. They should not need to be explicitly referenced anywhere else.

Additionally, whatever we come up with, I would also want it to work in a recursive fashion, that is to say: a module can use a module which uses modules ...

EDIT: Also, of course, this shouldn't just apply to actions dispatched from views. It should be the same for actions dispatched from Effects (whatever action initiated the effect), and subscriptions.

[jorgebucaran]

Here's how this could look like for Hyperapp.

First, define your button module:

import { h } from "hyperapp"

const Increment = state => state + 1
const Decrement = state => state - 1

export const init = 0
export const view = state =>
  h("div", {}, [
    h("button", { onclick: Decrement }, "-"),
    h("div", {}, state),
    h("button", { onclick: Increment }, "+")
  ])

In your main app, import the button and a new core function, e.g., map, that transforms all messages generated inside Button.view to something that makes sense for your main state.

import { h, app, map } from "hyperapp"
import * as Button from "./Button"

app({
  init: {
    button: Button.init()
  },
  view: state =>
    h("div", {}, [
      h("h1", {}, "Here's a button"),
      map(state => ({ button: state }), Button.view(state.button))
    ]),
  node: document.getElementById("app")
})

• How would you improve this API? and,
• if you know how Hyperapp works under the hood, how would you implement it?

[zaceno]

Another example, using the same module twice. I had to ask in the Elm-forum because it wasn't clear to me at the time. In hindsight, I realized I had misunderstood parts of how consuming a module works in elm and this cleared things up for me at least: https://discourse.elm-lang.org/t/using-multiple-instances-of-modules/4578

[jorgebucaran]

@zaceno How would you translate that into Hyperapp using what's currently proposed in #896 (comment)?

[zaceno]

@jorgebucaran It doesn't really change anything about your proposal. If I read it correctly (and understand what Elm's map does), it is basically:

map(actionTransformer, vnodes) -> mappedVnodes

Any onclick: Foo in vnodes will be transformed into onclick: MappedFoo in mappedVnodes, where MappedFoo is produced from actionTransformer(Foo).

Right?

[zaceno]

This approach requires no implementation in core and is so straightforward that I've certainly tried it before. But I can't recall what the problem was.

const namedScope = name =>
    action =>
        (state, payload) =>
            ({...state, [name]: action(state[name], payload)})

const Counter = scope => {
    const init = 0
    const incr = scope(state => state + 1)
    const decr = scope(state => state - 1)
    const view = state => (
        <p>
            <button onclick={decr}>-</button>
            {state}
            <button onclick={incr}>+</button>
        </p>
    )
    return {init, view}
}

const Main = (() => {

    const A = Counter(namedScope('A'))
    const B = Counter(namedScope('B'))

    app({
        init: {A: A.init, B: B.init},
        view: state => (
            <body>
                <h1>Here's two counters</h1>
                {A.view(state.A)}
                {B.view(state.B)}
            </body>
        ),
        node: document.body,
    })

})()

EDIT IV: removed edits II - III , since I don't think they added much to the discussion and make you scroll a lot 😛

[sergey-shpak]

Modules Implementation (I haven't tried this, only for the discussion purposes)
As usual, I tried to follow requirements:

1. simple and fits into current API (without any significant/complex core changes)
2. scalable and doesn't limit any functionality (dispatching 'sliced' or any normal action/effect at will)

Map. Since module actions are not exported directly, we can use vdom props to get the action references and decorate them, so map function becomes simple as

import * as Button from 'button'

const decorate = (vdom, getter, setter) => ({
  ...vdom,
  // recursive child decoration
  childrens: vdom.childrens.map(node => 
    decorate(node, getter, setter)
  ),
  props: Object.keys(vdom.props).reduce((obj, key) => {
    obj[key] = !key.startsWith('on')
    ? vdom.props[key]
    // wrapping module action with custom 'filter'
    : state => [
      vdom.props[key], 
      function filter(param){
        // and yes, filter which returns 'slice' function
        // 'param' is also available and can be passed 
        return function slice(obj){
          return obj ? setter(state, obj) : getter()
        }      
    }]
    return obj
  }, {})
})

const map = (fn, getter, setter) => 
  decorate(fn(getter()), getter, setter)

app({
  init: { button: Button.init },
  view: state => <div>
    map(
      Button.view, 
      () => state.button, 
      (state, button) => ({ ...state, button })
    )
  </div>
})

• please notice how module state is set (because getter should always return latest module state)

Button.

const increment = (state, slice) => {
  // now you have plenty options here
  // 1. you can call `slice()` to get sliced state (map getter)
  // 2. you can `return slice(2)` to set sliced state (map setter)
  // 3. you can dispatch sliced effect
  // like `return [slice(1), effect()]` or even passing slice further
  // like `return [slice(1), effect({ action: [ action, () => slice ] })]`
  // 4. at the same time you can change global state if needed
  // like `return { ...state, some: 'prop' }`
  // 5. or dispatch any not mapped (external) action
  // like `return [location, '/path']`
  return slice(2)
}
export const init = 0
export const view = state => h('button', {
  onclick: increment
}, state)

I haven't tried this on working example, but I can imagine this working.
@jorgebucaran @zaceno any thoughts?

[zaceno]

@sergey-shpak looks like a good possibility but how would you do it with payloads? And why the getter and setter? Why not just a single action transform?

[sergey-shpak]

@zaceno there are some pros and cons with this pattern, one of them that filters (payloads) inside of module should pass 'slice' function into action (also mentioned in comments but haven't implemented it yet - 'slice' filter also can pass param(payload) if any)

Since we can call sliced effects, getters and setters are used to return latest state, but I have to think about it more if I can simplify it

In general, main idea of this approach is quite simple - passing 'slicer' function as parameter into each module action, there are also some variations for dev userland

const action = (state, slicer) => {
  const slice = slicer(state) // get sliced state
  return slicer(state, 1) // set sliced state
}

[jorgebucaran]

@zaceno @sergey-shpak This feature must be in core.

[zaceno]

@jorgebucaran

This feature must be in core.

I'm not disagreeing, but could you clarify: Do you mean it is something you don't want to leave up to userland, or are you aware of a technical reason why it must be in core?

Here's a possible implementation of map outside core:

const map = (f, vnode) => ({
    ...vnode,  
    props: Object.entries(vnode.props)
        .map(([key, val]) => [key, key[0] === 'o' && key[1] === 'n' ? f(val) : val])
        .reduce((o, [key, val]) => ({...o, [key]: val}), {}),
    children: vnode.children.map(child => map(f, child))
}) 

It will impact performance the more it is used, but I don't know of a way to avoid that by implementing it in core.

[zaceno]

@sergey-shpak Is your solution really much different than #896 (comment) ?
You make sure that actions get the slicer as an argument. I just make the slicer available in the entire scope of the module.

Also: what are the pros/cons of that approach?

[sergey-shpak]

@zaceno we are working on the same task some approaches can look similar,
pros of #896 (comment) are:

• direct 'slice' injection into actions using existing filter api
• looks and reads simpler (component)

cons:

• passing params into action

[jorgebucaran]

@zaceno Do you mean it is something you don't want to leave up to userland, or are you aware of a technical reason why it must be in core?

Don't want to leave up to userland. No technical reason comes to mind, either. Well, maybe that it'd be hard to implement in userland?

[zaceno]

@jorgebucaran 👍

Well, maybe that it'd be hard to implement in userland?

Doesn't look like it. At least, the code I pasted above seems to do the trick. See this codepen where I use it:
https://codepen.io/zaceno/pen/gOOGzPr