Consider extract the routing code from core about hyperapp HOT 20 CLOSED

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

Should we get rid of the router?

Please 👍 👎 .

from hyperapp.

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.

from hyperapp.

@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

from hyperapp.

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

from hyperapp.

@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).

from hyperapp.

@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.

from hyperapp.

@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 #28

from hyperapp.

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

from hyperapp.

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

from hyperapp.

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

from hyperapp.

@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?

from hyperapp.

@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?

from hyperapp.

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

from hyperapp.

@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

from hyperapp.

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

browserify -t hyperxify index.js > bundle.js

from hyperapp.

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

from hyperapp.

@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.

from hyperapp.

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

from hyperapp.

from hyperapp.

from hyperapp.