Mithril.js: vanilla JS, modules and m.prop

[griebd]

Actually I don't know if I'm missing something, but...
I'm using mithril.js in a new project, I want to keep it as simple as possible so I'm using vanilla JS! I'm using the latest rewrite version (mithril.min.js) from here as I believe version 1.0 will come before I finish my project...

Anyway, my problem is that I couldn't find the modules to include when/if I need then, just the core one mithril.min.js!
Is the idea that I need to build then myself? If so, why provide the core itself?
I think the project should provide then all or let the user build then all! Providing the core and letting the modules out will cause confusion.

[lhorie]

mithril.min.js is a bundle of the core Mithril modules that exposes a single variable m to the global scope. It's intended to be used for codepens/jsfiddles or from a CDN

If you want to use CommonJS modules, you should include them directly, e.g var render = require("mithril/render") and use a bundler to create a bundled js file. The simplest way to bundle files is outlined in the installation page. Typically, you cannot use CommonJS modules directly in the browser because browsers don't support it.

But if you really really really want to use CommonJS modules without a build step, there's the CommonJS polyfill utility module/module.js

To use it, you'd do:

<script src="node_modules/mithril/module/module.js"></script>
<script src="node_modules/mithril/vnode.js"></script>
<script src="node_modules/mithril/render.js"></script>
<script>
(function() {
  var render = require("./node_modules/mithril/render")

  //do stuff
})()
</script>

I should note though, that while this is possible, it isn't a recommended workflow, since it has several drawbacks.

[griebd]

ok, then this become a bug report!!!! :wink:
in the latest version of mithril.min.js, in the rewrite branch, I can't use m.prop anymore... It is undefined!
It started when you moved the m.request back to the thenable promises.

[oliverhunt]

m.prop has been removed check the migration docs

[lhorie]

m.prop is now a stream micro-library and no longer part of the core distribution. After some dogfooding, I came to the conclusion it isn't actually necessary if you use a data flow similar to this:

var auth = {
    email: "",
    password: "",
    user: null,

    error: "",
    login: function() {
        m.request({
            method: "POST",
            url: "/api/auth",
            data: {
                email: Data.auth.email,
                password: Data.auth.password,
            }
        })
        .run(function(user) {
            auth.email = ""
            auth.password = ""
            auth.user = user
        })
        .catch(function(e) {
            auth.error = e.message
        })
    }
}

var Login = {
    view: function() {
        return m("form", {onsubmit: auth.login}, [
            m("label", "Email"),
            m("input[type='text'][placeholder='email']", {
                value: auth.email,
                oninput: m.withAttr("value", function(v) {auth.email = v})
            }),
            m("label", "Password"),
            m("input[type='password'][placeholder='password']", {
                value: auth.password,
                oninput: m.withAttr("value", function(v) {auth.password = v})
            }),
            m("button[type='submit']", "Login"),
            auth.error ? m(".error", auth.error) : null,
        ])
    }
}

[griebd]

@oliverhunt, I have actually checked the migration doc... But I will do it again, I may have missed something along the changes! By the way, all people involved deserves congratulations for keeping such a nice documentation! (I'm terrible in doing that :wink:)
@lhorie , ok then, so I need to change my code a bit! thanks for the guidance!

[lhorie]

@griebd I'm just echoing a similar convo from the chat here, but you can still use m.prop by referencing this URL: http://cdn.rawgit.com/lhorie/mithril.js/rewrite/util/stream.js