Reusable components.

[vivekimsit]

Hi,

What about creating a repo which contains a set of reusable UI components? something like Angular-UI or Khan Acacdemy

I am ready to contribute.

Cheers!

[StephanHoyer]

We all thought about this, finally one is speaking it out ;)

I think there are a few problems to solve. Everyone has opinions about how thinks has to be solved so these components should be flexible enough.

This is normally done with configuration. But if you do this, the components tend to get quite complex and large.

On the other hand, with mithril things got quite simple to implement. So in most cases it is easier to reimplement your component specific to your usecase.

Other questions that arise:

• What module system (plain/AMD/CommonJS/ES6)
• Dependencies between components and to utilities (e. G. lodash)
• 1-repo-per-component (ampersand) or 1 repo for all components or something between
• ...

This shouldn't keep us away from doing it. Maybe open-source-evolution will figure this out.

[vivekimsit]

Yes,

From this project we will learn:

1. How awesome mithril is.
2. How to creates components which are easy to compose.
3. Mithril best practices which others can follow.

Would like to listen from others too :)

Thanks!

[StephanHoyer]

just found https://github.com/mithril-ui

Seems monolithic and outdated. Also it's bound bootstrap what I personally don't like.

There is also https://github.com/ng-vu/mithril-bootstrap from the same person (@ng-vu)

[eddyystop]

Satyam and I wrote one of the earliest component repos https://github.com/eddyystop/mithril-components. We thought then a standard set of Mithril components was important to acceptance, and I still think so now.

The problem has always been the lack of a canonical component design that turtles all the way down, and allows some components to expose some of their state to others. You'd want components from different authors to play nice with one another.

Like other people, I've rolled my own components, including some sophisticated ones, yet they can't be shared.

[iOliverNguyen]

Hi guys,

I created mithril-bootstrap just for experience how to structure projects and components in Mithril. For now, I agree that it's easier to reimplement components for our specific usecases or wrap other libraries in Mithril-style than force everyone to follow a single style.

JavaScript is evolving rapidly. Yesterday I used RequireJs, today Browserify and tomorrow maybe ES6 Modules. It's up to people to organize their projects and requirements.

[vivekimsit]

Ya, it would not be that trivial but I think its a good project to start with. After all it can show the real power of mithril.

WDYT?

[StephanHoyer]

@ng-vu Totally agree.

Thats why I also think the web-components movement is a dead-end. Easy-to-implement custom tailored components are the way to go. That's why mithril rocks ;).

So conclusion of this issue would maybe to create a list of possible patterns for mithril components where anyone can get inspired and inspire others.

Don't quite know how to achieve this. Maybe a wiki, but this tends to outdate.

Any ideas?

[tracim]

Hello,

I believe a component store would be very nice but I also understand
that a reusable component is very complexe to implement because of the
required flexibility.

What about a component snippet store ? You would be able to share your
components without to search for flexibility. Others can reuse and adapt
them to their own needs and maybe can share their new version with
different features.

For Boostrap related stuff, there is http://bootsnipp.com/ which offers
exactly this kind of stuff. You find code snippets which are ready to
use ; but most of the time you adapt them to your own needs.

Damien

Le 16/01/2015 11:50, Stephan Hoyer a écrit :

@ng-vu https://github.com/ng-vu Totally agree.

Thats why I also think the web-components movement is a dead-end.
Easy-to-implement custom tailored components are the way to go. That's
why mithril rocks ;).

So conclusion of this issue would maybe to create a list of possible
patterns for mithril components where anyone can get inspired and
inspire others.

Don't quite know how to achieve this. Maybe a wiki, but this tends to
outdate.

Any ideas?

—
Reply to this email directly or view it on GitHub
#413 (comment).

[eddyystop]

@tracim, I find the idea of a snippet store interesting. In addition to what you mention, it sidesteps the issue of what CSS to decorate the tags with e.g. custom classes (m-dropdown-component) vs Bootstrap classes.

[barneycarroll]

👍

I think this is a great idea. Too many people want stuff that just plug and plays, but the truth is you can't write terse and elegant plugins that accounts for everybody's intended usage and caters for all their desired configuration with totally plug-and-play code. People have tried to do this in the past and ended up with the huge bloated nightmares that are jQuery UI and Angular.

If anything, Mithril's philosophy is that functional code should be kept short and sweet and obvious, that way users can learn a little by looking into it and customise it to fit their situation.

Plus, this encourages development and configuration over dumb copy+pasting, which has got to be good for the community.

[vivekimsit]

👍

Snippet store seems interesting idea. That will be a kind of cookbook.

[jdnier]

A Mithril Cookbook would be a great resource, given the way people seem to recommend developing with Mithril (solving your own problems effectively and not writing a mini-framework about it). Having several recipes for solving a focused task can be useful when you're learning. Depending on your coding approach (functional, prototypal, class-based), there might be several idiomatic implementations for the same recipe. One concrete example of how this could work is ActiveState's language-specific cookbook recipes; several of the subsites have even been turned into O'Reilly books. Collecting recipes for solving common tasks would be a good start.

[lhorie]

If anyone wants to take a stab at organizing the wiki, feel free.

[zserge]

I agree that Cookbook or a collection of snippets would be a perfect way to learn Mithril and to help people make their own custom components. But Mithril needs to gain popularity and I think if a newbie will see just a list of recipes, and he won't be able to npm-install then to quickly test - he will be disappointed and will go back to React with their react-components repo. I personally find Mithril much more solid and useful than React. But I still have to use React because of its Material Design components, and because I can't assure my colleagues to use Mithril since nobody ever heard of it.
So recipes are important to learn Mithril. But pluggable components are important to start quickly use Mithril and to help it become popular.

[eddyystop]

@zserge are you referring to https://github.com/callemall/material-ui ?

[zserge]

@eddyystop Yes, subjectively it seems to be the most usable set of Material components to write mobile HTML5 apps (I've also checked Bootstrap Material, Angular Material and Polymer Project).

[vivekimsit]

Totally agree with @zserge

In fact to develop a strong community we need a strong POCs

cheers!

[eddyystop]

I would think callemall/material-ui custom less CSS would concern some people, as opposed to, say, Bootstrap 3. Any information on this?

I guess one idea is to keep someone's material UI less and redo the JS in Mithril.

[zserge]

@eddyystop You mean they're using different element classes than Bootstrap? I don't see a problem here, since these two are very different:

• As I see Bootstrap is handy to style individual elements on the web page. It's handy when you make a web page with content, or maybe with some simple forms.
• Material UI is useful when you want to make a full mobile application, so you get the building blocks - actionbar, side navigation, pickers, sliders etc.
  That's why the bootstrap material style is very fragile and barely works in mobile browsers.
  So ideally Mithril should have plugins for both, bootstrap and material UI.

And I totally agree that "borrowing" LESS styles from the material-ui would simplify things a lot. Or maybe from the Polymer, which also looks nice on mobile.

[eddyystop]

@zserge "Polymer is based on a set of future technologies, including Shadow DOM, Custom Elements and Model Driven Views." So its further removed from the Mithril philosophy than Material-UI or Bootstrap.

The Material-UI and Bootstrap CSS can force the HTML to be structured differently. So you'd need a separate library for each, though they would be similar.

[zserge]

@eddyystop Yes, I agree that Polymer is very different from Mithril and not suitable for porting. I copy-pasted some CSS blocks from there in the past to mimic material UI, so it's possible, but not convenient at all.

React's approach is much nicer, of course.

Also I don't think Bootstrap for Mithril and Material UI for Mithril would have any similar code at all.

Anyway, it looks like we agreed that Bootstrap and Material should be implemented for Mithril. Other ideas? If we make a list of components - we can decide how flexible they should be, probably some requirements and implementation details etc and actually we could start working on them.

[eddyystop]

@zserge, I replied in the Mithril google group ( https://groups.google.com/forum/#!topic/mithriljs/4C4xwYtanjY ) as that may be a more appropriate venue.

[eddyystop]

I'm comfortable with the info I've picked up in the Mithril google group. Is anyone at least semi-serious in developing a UI library?

[vivekimsit]

👍 of course I am the one.

[corymickelson]

Yes

[eddyystop]

My thoughts:

• I like the idea of using https://github.com/philtoms/mithril.elements as it makes components easier to use. You just m(...) components in your view as their controllers are created as needed for the majority of use cases. There are work-arounds for edge cases. (See https://groups.google.com/forum/#!topic/mithriljs/4C4xwYtanjY )
• I would lean toward using Bootstrap CSS first. Other CSS frameworks may involve some "missionary" activity to justify them. Popularizing Mithril is an effort, and having to popularize something else in addition would be harder.
• I wouldn't want multiple libraries trying to do the same thing.

My suggestion is that we contribute to https://github.com/philtoms/mithril-starter-kit. Its the starter library for mithril.elements and its based on Bootstrap. Its current components illustrate how to use mithril.elements.

One approach to contributions would be to take the Bootstrap docs

• http://getbootstrap.com/components/
• http://getbootstrap.com/javascript/
  and create pull requests for components not yet in philtoms/mithril-starter-kit.

I'll be rewriting components I have for dropdowns and for nav bars.

[pelonpelon]

Although I'm not a fan of the bootstrap look, I do think it's the appropriate choice if we want to popularize mithril.

Bootstrap makes extensive use of jQuery. I wonder if we might start out by formalizing 'standard' javascript snippets to replace jQuery equivalents, specifically in regards to functional programming and object manipulation. I'm not sure how to treat DOM manipulation vs. virtual DOM manipulation. That might require evaluation on a case-by-case basis. (I'm assuming we want mithril components to function without dependencies)

We might also want to start a 'best practices' guide.

I don't want us to get too bogged down, we should just start hacking now. But having a single source of truth early on might save a lot of refactoring.

[eddyystop]

I've converted various Bootstrap "javascript components" that use jQuery into mithril plus pure javascript. Its usually straightforward and the resulting mithril code is much easier to understand.

You just have to know what an action would cause and implement the effect in Mithril. Consider a dropdown. Bootstrap manipulates the DOM with jQuery to show or not show the dropdown items. With Mithril you check view-model state to see if the dropdown is open and render the items or not. Much simpler.

I implemented the complex Affix component ( http://getbootstrap.com/javascript/#affix ). Its the sidebar menu floating on the right of the page. You'll see it "land" when you scroll to the top of the page. The key was figuring out what Bootstrap's jQuery addon was doing to the DOM.

The take-aways are that its not hard to implement Bootstrap "javascript components" and that you shouldn't focus on the jQuery.

[barneycarroll]

Most of the time plugin behaviour consists of querying values and changing
'nearby' DOM attributes, which is trivial with Mithril. It's been mentioned
before, but things get a bit confusing if you've been using modules where
DOM hierarchy matches model hierarchy (why wouldn't it?) and suddenly you
discover a situation where that isn't the case (tooltips – crap!). I
recently came up with this pattern for defining a view in one place and
outputting it in another, which might come in handy for the many components
that require some form of overlay. http://jsfiddle.net/barney/Laxn4jem/

Regards,
Barney Carroll

barney.carroll@gmail.com
+44 7429 177278

barneycarroll.com

On 23 January 2015 at 17:19, Eddyystop notifications@github.com wrote:

I've converted various Bootstrap components that use jQuery into mithril
plus pure javascript. Its usually straightforward and the resulting mithril
code is much easier to understand.

You just have to know what an action would cause and implement the effect
in Mithril. Consider a dropdown. Bootstrap manipulates the DOM with jQuery
to show or not show the dropdown items. With Mithril you check view-model
state to see if the dropdown is open and render the items or not. Much
simpler.

I implemented the complex Affix component (
http://getbootstrap.com/javascript/#affix ). Its the sidebar menu
floating on the right of the page. You'll see it "land" when you scroll to
the top of the page. The work came down to figuring out what Bootstrap's
jQuery addon was doing to the DOM.

The take-away is that its not hard to implement Bootstrap "javascript
components".

—
Reply to this email directly or view it on GitHub
#413 (comment).

[pelonpelon]

It might be useful for anyone attempting to convert bootstrap-jQuery to bootstrap-mithril to take a look at https://github.com/react-bootstrap/react-bootstrap, especially for clues when to redraw and in rare cases when you need direct DOM manipulation.

I seem to remember issues with click responses on iOS and the need to get this directly from the DOM.

[l-cornelius-dol]

@barneycarroll : That's my central concern. It's not that the view context can't serve as a controller, nor that it shouldn't if you choose to use MVC, but that it shouldn't be inferred to be limited to that concept by it's name.

In fact, the documentation for Controllers makes my point for me:

In client-side MVC, however, this dissonance doesn't exist, and controllers can be extremely simple. Mithril controllers can be stripped down to a bare minimum, so that they only perform a single essential role: to expose a scoped set of model-level functionality. [emphasis added]

If that's not an argument that controller "should be" a view-model, I don't know what is. But it's really a stronger argument that controller is a view-context without a specifically defined purpose, per se.

It's taken me largely this long to figure out I can use the "controller" any way I darn well please, including making it a singleton or a closure scoped object. But doing that finds huge impedance within me, because my 35 plus years writing code has ingrained in me to use things the way they are designed to be used, or risk all hell breaking loose down the road. I realize that other programmers feel differently about playing fast-and-loose with API, but anyone with years of C experience pre-2000 quickly learned what a bad idea it was to rely on undocumented "features" of the C standard library functions.

I think the config context should just be called "config-context" as opposed to "view-context". Or maybe dom-context. They are the same concept with two specific applications of a "context". So I think I would rename that argument as I renamed my ctrl arguments.

(PS: I also think that widening the "controller" concept makes Mithril MVx, rather than just MVC, which in turn widens its appeal and lessens resistance from those people that think, "MVC is not where it's at, you should be using MVVM", or any other flavor. Look at the way ReactJS advertises itself as a pure view-layer unopinionated on the rest of the stack.)

[StephanHoyer]

I used scope since the beginning of my mithril usage. I think of controllers of functions not of results of functions or collections of them. That's why I always use scope. contextwould also an options I think.

[leeoniya]

viewctx or as Mercury defines is state, maybe viewstate all seem equally appropriate

[pygy]

FWIW, in JavaScript, the context is whatever thispoints to at a given time. While the term is not used often, it already has a well defined meaning.

Why did you chose not to bind this in the views? It neatly sidesteps these semantic considerations, and it makes neater CoffeeScript views :-)

[StephanHoyer]

To quote Gandalf here

[l-cornelius-dol]

@pygy : Because in JavaScript this has a really bad habit of changing in really surprising ways. I cannot commend Leo enough for having Mithril not depend on this.

And the problem is far worse if you come from languages where this has syntactic scope -- it's no surprise that every would-be-replacement of JavaScript abandons dynamically defined this for statically defined this.

[barneycarroll]

This conversation wouldn't be complete without my suggesting we find some kind of excuse to implement $scope.apply. Angular is really popular and developed for popular appeal too! ;)

[oren]

Even Douglas Crockford stopped using this - http://www.youtube.com/watch?v=PSGEjv3Tqo0&t=9m25s

(and also null)

[StephanHoyer]

My 50 cents on this

[barneycarroll]

Vote to close this issue and open separate threads for the various distinct issues under consideration.

[gilbert]

Agree. I'm going to create some right now

[tivac]

👍 to closing this.

[leeoniya]

@oren interesting that he doesnt mention Function.bind, which mostly solves this scoping issues.

[l-cornelius-dol]

Agree to closing this, but with links to the separate issues created from it in a final comment.

[lhorie]

Ok, yeah this thread is getting a bit unwieldy. Also, going by the speed of the replies, it might make sense to move the discussion over to Gitter

[l-cornelius-dol]

My vote: Please don't move these to Gitter; let's keep the history together here.

[lhorie]

Doesn't gitter have history too? I was just referring to this current convo, since there's like 5+ people currently online

[barneycarroll]

Yup

[l-cornelius-dol]

I think the major issues which have arisen in this thread are very close to consensus. They seem to be:

1. Components
2. Component repo.
3. The "controller" misnomer.
4. The "module" misnomer.

An new thread on these is only needed to bring each to a point of closure.

If separate threads were opened from this, I would consider transferring my most salient comment on each topic to the new thread to keep some context and continuity without newcomers needed to back reference to this one.

[pygy]

@lawrence-dol The dynamic scoping of this is indeed a bit annoying, but Mithril uses it already in what is still know ATM as controllers. I've always wondered why it was used there, but not in views.

That being said, I understand that it is a contentious issue, and I'm not attached at all to the proposition.

@barneycarroll can you link to a given point in the gitter history? I couldn't find how.

[gilbert]

Alright all, I've created three issues:

• Separate m.module into two separate functions Separate m.module into two separate functions #498
• Renaming m.module to m.component Rename m.module to m.component #497
• Rename "controller" to something else Rename "controller" #499

[lhorie]

@mindeavor awesome thanks! Closing this then

[l-cornelius-dol]

I suggest that once the smoke has cleared, and the components branch lands, we only then re-open a new issue on creation of a component repository, yes?

[lhorie]

@lawrence-dol makes sense

btw, gitter link, you can sign in w/ github credentials

[gx0r]

Thanks guys, this is awesome.