Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    dontwork
    @dontwork
    as a replacement for m.request?
    Hendrik Roth
    @HendrikRoth
    yes
    Stephan Hoyer
    @StephanHoyer
    I would probably use https://github.com/mzabriskie/axios for both
    Hendrik Roth
    @HendrikRoth
    i don't use m.request
    dontwork
    @dontwork
    i hadnt realised this
    i was getting an error from the xmlhttpreq mock
    Stephan Hoyer
    @StephanHoyer
    I currently use superagent for server side and m.request for client
    dontwork
    @dontwork
    thanks for the advice and lib recc, i will take a look in a min
    you like axios though?
    Stephan Hoyer
    @StephanHoyer
    havent used it. But a lot of people got back to it after trying fetch
    Hendrik Roth
    @HendrikRoth
    i used isomorphic fetch to drop the client side fetch if it is native supported everywhere
    dontwork
    @dontwork
    so is there no desire to make m.request isomorphic
    i guess its impossible because it relies on xhr?
    Stephan Hoyer
    @StephanHoyer
    that would be an option
    dontwork
    @dontwork
    just a shame its in the codebase but only works on browser
    especially when mithril-node-render is practically a perfect isomorphic solution
    except requests
    Stephan Hoyer
    @StephanHoyer
    it's pretty much a hyperscript2html converter only
    if you want more, you can easily build it using mnr
    dontwork
    @dontwork
    mnr?
    Stephan Hoyer
    @StephanHoyer
    mithril-node-render
    ;)
    dontwork
    @dontwork
    build what?
    Stephan Hoyer
    @StephanHoyer
    a complete isomorphic setup
    routing is another thing that is not supportet
    dontwork
    @dontwork
    this is what ive done
    im just setting up redux and i will have the whole 'rehydration' thing done
    Stephan Hoyer
    @StephanHoyer
    because erveryone has different opinions on this
    same goes for xhr
    dontwork
    @dontwork
    so its probably a worthless pursuit to develop m.request to an isomorphic solution?
    brb lunch
    Stephan Hoyer
    @StephanHoyer
    but building a server-side m.request should't be that big of deal I think
    dontwork
    @dontwork
    Do you think it would be a welcome addition
    pretty neat
    maybe i'll add this to the isomorphic example
    dontwork
    @dontwork
    Sweet!
    dontwork
    @dontwork
    thanks for that @StephanHoyer pretty simple drop in!
    Im using it!
    Stephan Hoyer
    @StephanHoyer
    👌
    Stephan Hoyer
    @StephanHoyer
    updated and simplified version of mithril-isomorphic-example just git published
    now with m.request running server and client side, so no need for a store facade, thanks @dontwork for the inspiration
    dontwork
    @dontwork
    😊
    Hendrik Roth
    @HendrikRoth
    +1
    Stephan Hoyer
    @StephanHoyer
    StephanHoyer/mithril-isomorphic-example@ce6e67c
    dontwork
    @dontwork
    @StephanHoyer do you still have the example where you hooked up the server-rendering straight to the api code rather than using the polyfill?
    Stephan Hoyer
    @StephanHoyer
    just look at the history
    Ben Chauvette
    @bdchauvette

    Howdy @StephanHoyer! Apologies for the text dump, but I figured I'd reach out on gitter before opening a bunch of issues on github.

    I have some free time this weekend, and I'd like to help out with mithril-node-render (and work towards some hacktoberfest swag :sweat_smile:).

    If you're interested in any of the following ideas, I'll open some issues for more discussion, then I can work on some PRs:

    1. Make the new isClass function match how Mithril itself checks for class components: i.e. classes don't have to actually use class syntax, they just need to be functions that have a view method on their prototype. This would simplify the check, and prevent possible incompatibilities between mithril and mithril-node-render.

    2. Move mithril to a peerDependency: This is how react-dom and React Native handle their depedency on React, and would help prevent issues like #58 in the future. I imagine most users consuming this module probably already have mithril installed as a dependency, so you wouldn't run into the peerDependency hell that you do with e.g. eslint plugins and presets.

    3. Update documentation a bit: There's a few minor grammar hiccups, and a couple areas that I think could use a bit more clarification (e.g. escaping).

    4. Switch from co to async/await: this would be a breaking change and would only work on node >=8, but it would remove the dependency on co and I think make the code slightly more idiomatic.

    5. Implement #65: I feel like this would be a pretty big change, but I could take a stab at implementing it as e.g. renderSync. With async/await becoming more mainstream, though, I don't know how relevant this still is?

    Stephan Hoyer
    @StephanHoyer
    1-4 :thumbsup: