Hyperapp: Consider extract the routing code from core

[danigb]

Hi @jbucaran,

I felt in love with hyperapp because is almost the perfect essence of the Elm application architecture. All the code is clean, simple and functional 👍 The only part that looks a little bit hacky is the routing code. But there are other reasons to extract it:

• Not all applications need routing. That would help to reduce the size of the core.
• Even if they use routing, is not always to change the view.

I don't know the best solution (that's why I'm opening this issue), but I think the API could be something like:

import { html, routes, app } from 'hyperapp'

const model = {}
const view = routes({
     "*": (model, msg) => {},
     "/": (model, msg) => {},
     "/:slug": (model, msg, params) => {}
    }
})

app({ model, view })

The new routes function should create a view (function) that selects the route proper view function using the browser history, and previously it registers the required event handlers, probably using the lifecycle events (more or less, the same code now it's inside the app.js file)

What do you think?

Anyway, congrats for this nice library

[FlorianWendelborn]

@danigb I'm generally in favor of extracting it, but note that this will lead to people using different routing solutions that may not interoperate well with each other.

That in itself is not a problem, but the thing I like about hyperapp is that it's basically React+Redux+React-Router without any problems (React-Redux, Redux-Router) when trying to combine all of those (and of course the file-size).

[tunnckoCore]

@danigb I've done it in 600 bytes :) last night and it is available at https://github.com/tunnckoCore/gibon and https://unpkg.com/gibon (i'm writing docs now). It is pretty customizable and works well with nanomorph, bel or any other.

edit: I'm in process to extract the "diffing" thing, so we can see if we could build hyperapp from smaller parts and remain the same size.

[tunnckoCore]

But yea, in anyway it should be in the core. Because the purpose of the hyperapp is to be kinda "complete" solution for building apps.

[itrelease]

@jbucaran @maraisr it's also would be nice to move helpers/utils function in their own modules so they can be reused as I did in https://github.com/hyperapp/hyperapp/pull/28

[jorgebucaran]

@itrelease Yeah, but this would create a slightly larger bundle.

[itrelease]

@jbucaran I think that 1kb shouldn't be a selling point of hyperapp. I'm with you on keeping it as small as possible but not paying for this by poor code base

[tunnckoCore]

@jbucaran I believe @itrelease means to separate helpers into new local file. It won't add additional bytes, because Rollup is smart enough.

[tunnckoCore]

@itrelease i'm :+1: here. Also it is not really 1kb, fully functional is ~3.5kb - meh... don't know.

[jorgebucaran]

@tunnckoCore What your users will consume is what matters? And what they will consume ~1.6ish kb.

If you mean the codepen examples, etc., sure it's 3.1.

@itrelease I think that 1kb shouldn't be a selling point of hyperapp.

Why not?

[itrelease]

@jbucaran because at some point I think you would need to add some feature or fix bug that would lead to bigger bundle size but I guess it would be more important than keeping 1kb?

[jorgebucaran]

@itrelease Yeah, that's not unlikely. I'll see if rollup is smarter than browserify here as @tunnckoCore said.

[tunnckoCore]

@jbucaran it is the father and mother of the tree shaking, it always will be better then the others.

As about the size... 1.6kb gzip is for JSX users

[jorgebucaran]

@tunnckoCore Yes, and also for Hyperx users alike, if they bundle with hyperxify.

browserify -t hyperxify index.js > bundle.js

[SkaterDad]

That is one of Rollups big selling points: It merges all of the modules together, as if you had hand-crafted a single file.

[jorgebucaran]

@SkaterDad In that case I apologize for my impatience. Browserify didn't do this for me, but rather created small little UMD modules all over the place. Maybe my setup was iffy.

[jorgebucaran]

@danigb You still want to get rid of the router?

Should we get rid of the router?

Please 👍 👎 .

[FlorianWendelborn]

@jbucaran I'm against "getting rid of" it, but making it an optional import would be nice.

[danigb]

Hi, I think would be nice to have it, but I didn't find time to think a
good alternative, so it's ok to me to close this issue 👌

El vie., 10 feb. 2017 16:33, Florian Wendelborn [e-mail]
escribió:

@jbucaran https://github.com/jbucaran I'm against "getting rid of" it,
but making it an optional import would be nice.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hyperapp/hyperapp/issues/47#issuecomment-278975911,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAdIbum1716r2JC4_bBMfilbpCjlgkjks5rbINBgaJpZM4L4sEP
.

[jorgebucaran]

tl;dr

• Let's remove the router. Why?
  
  
  
  • Not all applications need routing.
  
  
  • Reduce size of app.js
  
  
  • Too coupled with app.js, makes it difficult to test.
  
  
  • Router implementation is trivial, no query string handling.
  
  
  • Even if you use routing, it's not always about changing the view.
  
  
  • No support for hash-based routing
  
  
• Solution involves having app return a render(view: View) function.
• No API changes in app.
• Router API would be one of the following:
  
  
  
  1. Router.app({...})
  
  
  2. Router(app({...}))
  
  
  3. Router.start({...})
  
  
  4. Router.start( app({...}) )
  
  

---

I've considered this issue again and I'd like to proceed with removing the router from app.js and also from this repository.

The current router implementation is "okay" for simple usage, but it's not fair to limit users from using a great router implementation due to HyperApp size goals, etc.

I've been fiddling with how the API would look like and I've come up with two approaches. There's actually a third one that looks similar to what @danigb proposed, but it requires app.js to know about pushState and that there is a router, etc.

I used the name Router in the examples, but this is also open to discussion. Router probably has the best search-ability, but Navigator was also an eye-candy.

A

Router.app({
    model: 1985,
    view: {
        "/": (model, msg, params, setLocation) => {
            console.log("!!!!", setLocation)
            return (
                <div>
                    <h1>Home</h1>
                    <button onclick={_ => setLocation("/about")}>About</button>
                </div>
            )
        },
        "/about": (model, msg, params, setLocation) =>
            <div>
                <h1>About</h1>
                <button onclick={_ => setLocation("/")}>Home</button>
            </div>
    }
})

B

Router.start(app({
    model: 1985,
    view: {
        "/": (model, msg, params, setLocation) => {
            console.log("!!!!", setLocation)
            return (
                <div>
                    <h1>Home</h1>
                    <button onclick={_ => setLocation("/about")}>About</button>
                </div>
            )
        },
        "/about": (model, msg, params, setLocation) =>
            <div>
                <h1>About</h1>
                <button onclick={_ => setLocation("/")}>Home</button>
            </div>
    }
}))

C

app({
    view: Router({
        "/": (model, msg, params, setLocation) =>
            <div>
                <h1>Home</h1>
                <button onclick={_ => msg.setLocation("/about")}>About</button>
            </div>,
        "/about": (model, msg, params, setLocation) =>
            <div>
                <h1>About</h1>
                <button onclick={_ => msg.setLocation("/")}>Home</button>
            </div>
    })
})

/cc @dodekeract

[danigb]

Great! That's good news. I'm against app.js know about pushState. I did a
proof of concept where router used the model to store the current route,
but that enforces to use an object model, and I'm not sure it's a good
opción.

Your A alternative looks good to me. It's important to define a good api
between router and app yo allow different router implementations.

I think the app.js will benefit a lot from this change 👌

El sáb., 11 feb. 2017 7:57, Jorge Bucaran [e-mail]
escribió:

I've been considering this issue again and I'd like to proceed with
removing the router from app.js and from this repository. The current
router implementation is fine for simple usage, but it's not fair to limit
users to use a great router implementation due to HyperApp size goals, etc.

I've been fiddling with how the API would look like and I've come up with
two approaches. There's actually a third one that looks similar to what
@danigb https://github.com/danigb proposed, but it requires app.js to
know about pushState and that there could be such a thing as a router.

I used the name Router in the examples, but this is also open to
discussion. Router probably has the best search-ability, but Navigator was
also an eye-candy.
A

Router(app({
model: 1985,
view: {
"/": (model, msg, params, setLocation) => {
console.log("!!!!", setLocation)
return (

Home

)
},
"/about": (model, msg, params, setLocation) =>

About

}
}))

B

Router.start(app({
model: 1985,
view: {
"/": (model, msg, params, setLocation) => {
console.log("!!!!", setLocation)
return (

Home

)
},
"/about": (model, msg, params, setLocation) =>

About

}
}))

C

app({
view: Router({
"/": (model, msg, params, setLocation) =>

Home

,
"/about": (model, msg, params, setLocation) =>

About

})
})

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hyperapp/hyperapp/issues/47#issuecomment-279126408,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAdIZLnSAVeuT4JutxGKkjOElvYwsqUks5rbVvxgaJpZM4L4sEP
.