Skip to content

[rewrite] Rest of the API #1044

Closed
Closed
@dead-claudia

Description

@dead-claudia

Since we're starting to get to that point, I think it's a good idea to start thinking of the rest of the high-level API. Here's some of my ideas:

  • Mithril.m(type, attrs?, ...children)

    The familiar m() hyperscript API.

  • var trust = Mithril.trust

  • var mountpoint = Mithril.mount(window = global.window)

    Ideally, this should return an object you can use to do m.redraw()-like things and have multiple independent roots. The argument is for easy mocking, and effectively nullifies m.deps.

  • mountpoint.window

    This is the window value argument passed to Mithril.mount(), defaulting to the global window. You can also use a JSDOM window if you want to use it in Node.

  • var promise = mountpoint.redraw()

    This should do the equivalent of 0.2's async m.redraw(), but return a Promise.

  • mountpoint.redrawSync()

    This should do the equivalent of 0.2's sync m.redraw(true), and return nothing.

  • mountpoint.redrawStrategy = "all" | "diff" | "none"

    This fufulls the same purpose as m.redraw.strategy(). It might not be necessary with the lifecycle methods, though.

  • var promise = mountpoint.compute(callback: () => Promise | void)

    This should take the place of m.startComputation and m.endComputation. It is roughly equivalent to the following code:

    m.startComputation()
    return Promise.resolve(callback()).then(() => {
        m.endComputation()
    })
  • Mithril.prop(init?, observer?)

    m.prop is popular enough that it should probably stay in core. I do believe it should lose the Promise absorbing semantics, though, and it should be optionally observable.

  • Mithril.withAttr(value, callback, thisArg)

    m.withAttr also seems popular enough that it could remain in core, with few modifications (mostly removing compat bloat).


The rest are generally not necessary/needed in the core distribution.

  • m.route can be implemented on top of m.mount in a third-party module.
  • m.component can (and should) die.
  • m.request should be go away in favor of the native Fetch API, and there is an XHR-based polyfill if you need one. IMHO, redraw after request should be explicit, anyways.
  • m.deferred and m.sync should go away in favor of native Promises. If necessary, there's a ton of libraries and polyfills for that.

/cc @tivac @lhorie

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions