Proper documentation for objects

[devel-pa]

Hi,

Sorry for this issue, maybe I have to study more the source code, but is really boring without some docs.

I don't understand what is the structure of a component. What is list or style and what is especially vm and why they are used. And the fact that they are used in different ways in different contexts.

Please, some directions on the conventions you are using.

My major issue with that is how I can throw an external event to a component, how I will update a component when data arrives from the server, and especially a model, not a list. How I decouple the component from the data source.

So many questions.

I've studied some of the examples found on GitHub (and most of them are horrible written) and I understood from there that if I update the list the component will rerender.

In the end I want to point that the performance of Mithril is astonishing and I wouldn't bother with it if it wasn't. But really, I prefer reasonable documented stuff that tells me how to start (and I'm talking about data driven applications, not localStorage interface).

Think first at the developer, please, is how you'll make a bigger community.

Sorry again for this complaint and keep up the amazing work you're doing.

Paul

PS: if you have the stuff about I was talking about in your github docs, please, point me to it.

[chexxor]

To start with, we need to check what you have seen.

Have you seen the docs on the main site?

http://lhorie.github.io/mithril/getting-started.html http://lhorie.github.io/mithril/mithril.html

And also, to help with app design and conventions, have you seen Leo's incredible blog posts?

http://lhorie.github.io/mithril-blog/

[barneycarroll]

As @chexxor says, I would seriously recommend reading the guide and the blogs. If something's still not clear after, try the Mithril mailing list: it's much better for conversation and explanation than Github (which is better for bugs, feature requests, etc).

[devel-pa]

Hi, I read all of the pages you gave me, plus some others. The way code is done is a little strange to me as I prefer CommonJS style, and I have experience with Backbone and React. (and for sure Backbone way to structure objects) I promise I'll start again with "getting started" and try to create something more familiar for me. Thanks again, Paul

[lhorie]

Hi @devel-pa. Did you have issues understanding the example on the homepage? That is a minimal example that fetches data from a server, then renders it, then allows the user to modify the data via events.

A component (aka a module) is simply an object that looks like this: {controller: function() {...}, view: function() {...}}. You can read more about them here.

To understand how to work with data that comes from a server, I'd recommend reading the page on web services

Re: decoupling data from components, I wrote an article here

Another page that may help demystify some concepts is the one about the auto redrawing system, which talks about how Mithril re-renders after a change is made in the data layer.

Let me know if there's anything in specific that you're still having trouble with.

[devel-pa]

Yes, Part of your getting started example looks now like this:

/// start Backboneification
var extend = require("compose-extend");
var bindAll = require("lodash.bindall");
var Model = ViewModel = Controller = Collection = function() {
    if(this.init) this.init.apply(this,arguments);
    bindAll(this);
};
Model.extend = ViewModel.extend = Controller.extend = Collection.extend = extend;
Collection = Collection.extend(Array.prototype);
/// end Backboneification

var TodoCls = {
    Model: Model.extend({
        init: function (data) {
            this.description = m.prop(data.description);
            this.done = m.prop(false);
        }
    }),
    Collection: Collection,
    ViewModel: ViewModel.extend({
        init: function () {
            this.list = new TodoCls.Collection();
            this.description = m.prop("");
        },
        add: function () {
            if (this.description()) {
                this.list.push(new TodoCls.Model( { description: this.description() } ));
                this.description("");
            }
        }
    }),
    Controller: Controller.extend({
        init: function() {
            this.vm = new TodoCls.ViewModel();
        }
    }),
    View: function(ctrl) {
        return m("html", [
            m("body", [
                m("input", {onchange: m.withAttr("value", ctrl.vm.description), value: ctrl.vm.description()}),
                m("button", {onclick: ctrl.vm.add}, "Add"),
                m("table", [
                    ctrl.vm.list.map(function(task, index) {
                        return m("tr", [
                            m("td", [
                                m("input[type=checkbox]")
                            ]),
                            m("td", task.description()),
                        ])
                    })
                ])
            ])
        ]);
    }
};

var todo = {
    controller: TodoCls.Controller,
    view : TodoCls.View
};

[lhorie]

Ok, so Is there anything in specific that you're having issues with?

[devel-pa]

Yes, making components and using them. I'll start today some tests.

[devel-pa]

In the documentation you have m.module(document.body, ... which recreates html and body tags under body. PS: My mistake, works ok

[devel-pa]

Now I realize that your library has nothing to do with componentization/widgetization even if it claims that. Controllers are tight coupled and a bunch of disconnected from the controller static views. The proof is here: http://lhorie.github.io/mithril/components.html No way to scale a big application with dynamic views, at least not that way. Instead of components I will name them helpers or nested templates at most.

[lhorie]

I'm still not entirely sure what is the issue being reported.

Controllers are "tightly coupled" in the sense that if you're nesting things, then by definition the top level items require their descendants. It's perfectly possible to decouple sub-components so that they are reusable (as illustrated in the components page and here).

Views are decoupled from controllers because... why should they be tightly coupled?

To be honest, I don't really see how it's not possible to scale a big application using this framework. At the end of the day, everything is a just bunch of plain vanilla parameterizable functions, so there should be nothing stopping you from doing whatever it is that you expect components to do.

I've been using it for some relatively non-trivial projects, and haven't run into limitations, but if you have, please give me a specific example.

It sounds like you're expecting components to be analogous to React classes. You could write a small helper function if you want to write Backbone-ish/React-ish classes and make it output a Mithril module, or do this

[devel-pa]

I don't want to enter in any polemic and I understood that your framework is young and have some sins like any other framework.

I read your framework comparison and safety part (at the bottom of the main page) and there are some misunderstandings about your competitors. (Backbone MVC - is not, looks a little, React is template engine - is not, it is a view engine and is not MVC, just V, Backbone template safety issue - BB has no template engine, the one used there is Underscore template engine, try using other, Handlebars?), Angular is not MVC.

Also, your framework is an MVP as the app view knows about the controller (sent as parameter by your framework)

I also seen big performance drops on larger pages and not so big difference on rendering on moving circle demo. That happens because your framework renders everything even nothing is changed on data for interface.

My idea is that in fact every area of the page is a little MVC application.

In fact I've tried to build a BB/R-ish stuff and Mithril is so restrictive and light that I've run into plenty of issues. As of today it works, but when I've realized that "onChange" event in your demo triggers a full render of the application I stopped.

I'll stop here, my mindset is not prepared for Mithril, I have a lot against ServerSide concept applied to ClientSide and I consider Mithril usage too restrictive (try to achieve flexibility like Backbone + Mithril, Angular + Mithril, Director router + Mithril).

Thanks a lot for your time and excuse me if I said something inappropriate or wrong. Keep the good work and make Mithril better.

Best Regards, Paul

[barneycarroll]

@devel-pa a few misconceptions:

your framework renders everything even nothing is changed on data for interface

Incorrect. When and how Mithril performs redraws is explained in detail in the docs: by default, Mithril will redraw everything when a route changes, and will perform a diff - redrawing only the parts that change - when an event handler is executed. Of course, you can change all of this behaviour: the docs even explain specifically how to change the behaviour you've misunderstood.

the app view knows about the controller

If a view doesn't know about the controller, how will it access that controllers methods and properties? This is a basic necessity.

Director router + Mithril

I believe (as do many other people building full applications with Mithril) that Mithril's MVC is very useful. The routing component is very lightweight, but this makes it more flexible: I had considered using a third party routing library with Mithril (which is possible) but the advantages provided by m.route are just too numerous. If you're interested in extending Mithril's routing functionality, you may be interested in a plugin I'm developing, Moria.

[lhorie]

Ok. If I may be blunt, so far you've been coming across as rude and misinformed.

It doesn't seem like you've done more than skim the docs before making grand statements about integration with other frameworks and it seems like these conclusions are more based on rationalizations from emotions than research. To make a counter-example, it would be unfair for me to say Backbone is "so restrictive and light that I've run into plenty of issues" if this conclusion came from me trying to shoehorn Backbone into Angular in some stupid way and failing as a result.

It's certainly possible to integrate with other frameworks (even notoriously monolithic ones) and it's also possible take control of the rendering lifecyle by using m.render, but obviously, if you introduce another framework to give your code MVC/MVVM/MVP structure, Mithril modules become redundant, and you're responsible for evaluating which parts of Mithril you want to keep in your setup, since at that point you've diverged from idiomatic usage.

I'm more than happy to help get people unstuck if they have specific problems, but so far you've been mostly saying generic passive-agressive things like "Mithril is so restrictive", which is the equivalent of a bug report that says "it's not working, your system is broken" for a PEBCAK issue. That's not constructive, it's not professional, it's not actionable and it's aggravating.

[fyyyyy]

@devel-pa

Mithril is so restrictive and light

By light, do you mean that mithril is simple ? And by restrictive that it's not easy to use ? After spending some time with mithril, you will find this are two of its best qualities :+1: http://www.infoq.com/presentations/Simple-Made-Easy

[devel-pa]

I apologize if I offended you. I didn't wanted to be rude. I wanted to be constructive and point to some things that are wrong in your website/documentation (there are more). Looks like I've failed. I'm very sad about that.

I've made my point, with all the sins and misunderstandings of one week of hard study (certainly not enough).

You're framework can have a nice future, but my mindset is not prepared for its current state. I can't be more constructive as it diverges drastically from my personal view about UI.

Even if I want to answer your theoretical stuff about MVC (ASP.NET MVC, the view has no clue about the controller, same BB - something like a ViewModel is sent inside) / MVP (seen in java world, I don't remember if Angular, for sure GWT) and others, as I told you, I don't want any polemic.

Sorry.

Paul

PS: If you still want to here opinion against yours, I'm certainly available as you were very kind in helping me studying Mithril. But it saddened me this reactive answers on somebody that doesn't agree/understand your views.

[devel-pa]

To try to be more constructive, here is my third version of the study, the ugliest but most promising. There are missing parts, not time to copy/paste them safely from the other versions (like attributes and children for custom elements).

The code is junk and maybe not your way of architecting stuff. Also contains some stuff that I had to do but I don't like.

https://github.com/devel-pa/mithril-mantle

The main file where is some stuff for demo purpose is src/main.js.

The library built around Mithril is in src/mantle.js

I assure you that the example from http://lhorie.github.io/mithril/getting-started.html in Summary section renders full the application "onChange" event (when living the field render once, when living the field and clicking the button renders twice - normal, 2 events). That's why I think the MVP model is wrong in this particular case (Mithril) and ViewModel (MVC) should be sent in view and observed if something is changed (state).

In fact the example is doing somehow like this, with controller as accessor, the issue there is the description property that changes the state of VM. Hmm, no clue how to suppress it. I will like to see a m.prop that sets to none strategy when used and after changes back to the default one (this.description = m.prop("", true)).

The word 'Backboneifications' inside just point that the objects are working somehow like in BB (extend, events) but the result is React-ish.

Also I've tried in a different version hierarchical modules or another version using ma as you are using m. That delivers big performance loss as I had to instantiate all the objects for each render.

I really liked the way it goes, until I discovered that renders everything, every action I'm doing.

Can we do multiple modules in top of the main module and each submodule act independently?

[barneycarroll]

@devel-pa what you're talking about is definitely possible, but it's difficult to have this conversation on Github: Github issues are for reporting bugs or requesting features, but your problems are relating to documentation and application architecture - we should be having this conversation by email.

Could you start a new email thread in the Mithril Google group? There are plenty of people there (myself included) who can help with your issues!

[devel-pa]

Never used. I'll do that