Mithril as UI Lib

[giancarlocp]

Mithril as UI (virtual-dom) Lib

The functional programing (FP) philosophy is more than I will say, but I want to focus on this:

Do a small functions that does only one thing.

The discussion is:

Does Mithril want to have FP style/structure?

If Mithril wants to fit in there, it would be better split it in some packages.

The Mithril's goal is to be an UI lib, and it does it pretty well.

As an example, Redux-thunk is the smallest package I know.

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function')
      return action(dispatch, getState, extraArgument);
    return next(action);
  };
}

I have used Mithril for small tasks, so I have used a small part of its API. Maybe there is more to split, if this is approved.

The following are not UI related functions.

• Mihtirl-request
• Mihtirl-route (explained below)
• Mithril-stream

I always use stream. But others maybe not.

I do not use request -> fetch works. Maybe someone prefers axios.

Route is another history, I'm going to quote a section entitled "Waxing eloquent" from chapter 9 of the Joreteg's Redux book (Recommended).

"Many times, we over-engineer by creating generic solutions that include solutions for problems we don't actually have. It's tempting to use large routing libraries just because of their pretty APIs when all we really need to do is match a couple of strings."

I'm not saying Mithril-route is big, it isn't. He argue that Route is an "App state" problem and uses Redux (of course) to deal with it. Meiosis's route is coming.

With this we give the freedom of choice, and we don't have to carry on extra weight, download code will never be used.

[giancarlocp]

After a code glance, I have noticed queryString is a common dependency to Mithril, Request and Route. Check buildQueryString and parseQueryString

[dead-claudia]

@giancarlocp You might be interested in my in-progress API rework, which aims to decouple quite a few things more properly. It's all pre-proposal stuff, but it's getting close to being ready for an actual concrete proposal. And in particular, one of my plans in that proposal is that routing can be used in the view, but it doesn't have to.