Initial feedback - Githubissues

By hacking cli.js to take an argument I was able to get the development version of an app I'm building on Next.js working with rakt. You can see the branch here: https://github.com/CityOfBoston/311/tree/rakt

“Bugs”

[ ] The CLI was sensitive to the file path. running rakt ./pages/index.js generated the wrong module hash, but rakt pages/index.js worked.
[ ] rakt needs to set a __webpack_public_path__ to / in order to work when routes have subdirectories
[ ] The build script in package.json didn’t work without adding a .babelrc that included the react preset
[ ] Calling fetch on localhost to get the initial request data I believe will not work on Heroku. It would be nice in any case to make that more internal.

Overall Feedback This is very exciting for me. If you look at my commit adopting rakt I was able to clear out an entire GraphQL setup that was just there to communicate between my server and client (I’d rather over-do a GraphQL server than deal with REST endpoints at this point, though.)

While the rakt command was neat for starters, I expect that I’d want to have my own server startup and integrate rakt as middleware or a handler. That would let me handle config, logging, and any other extra things that I wouldn’t expect or want rakt to handle.

I’m nervous of the way the rakt babel plugin searches for components that match react-router names. I’d be willing to put up with a little more boilerplate in defining Route render methods in order to feel like there was less magic there. I understand if that’s not feasible, however.

Specific Feedback I’ll want to do dependency injection to get data-providers into my @initial blocks (rather than require singletons). This could be achieved by putting in my own middleware that attaches objects to the req, though it might be nicer to provide a function that rakt will call for every request that returns a “context” object that’s passed to @initial blocks.

Making the <Route> matched params available to the @initial blocks in some way would be helpful, especially for RESTful URLs that do a lot in the path. That way the code in @initial doesn’t have to re-parse the URL, which could get out-of-sync with the react-router matching.

I’d be interested if rakt didn’t require glamor or react-helmet, and had hooks for me to choose those or not as appropriate.

Thanks! Let me know how I can help. I’m particularly interested in how to integrate this with an existing server and also how to get the initial SSR rendering to include the fetched data.

routes having subdirectories, related #3. I'm doing a dirty regex string match thing, must strengthen the logic.
I've never even built the project myself yet, the package.json build line was just a placeholder ha.
the heroku thing is interesting. what's the recommended way to do a request locally on heroku?
the react-router thing - so yes, I see how that's a problem, related #2 - I mean for the plugin to be used with any component that takes a 'route' and a render/children func. The idea is for this to be a configurable via babel plugin options, so you can tell what module the route component is from, and what the name of the component is. (And then, the bigger idea is for it to pull out/rewrite these deps from any syntactic form; a decorator on a component? static class property? who knows!) Only thing stopping this stuff, is an implementation :)
Making this a generic middleware for express is a definite target, however I'm not sure how close I am to that yet. Will make a separate issue for the same.
so, regarding dependency injection. How's this for an idea -

@middleware(({req, res, next}) => {
  req.random = Math.random()
})
class App extends React.Component {
  render() {
    return <div>
      my app!
    </div>
  }
}

We could parse this out like we do initial calls, and set it up in the server that we start up. Then, every @initial component's req has access to req.random.

(Similarly, I'm thinking of a @setup(app => {...} directive, that'll be run only once when the server starts up.)

I'll remove glamor and react-helmet, they were just a test really. I want to move towards next.js' pluggable model.
quick note on your integration - I ❤️ it! I'll get some code in, such that if the function is async, you should be able to just return a value/ throw an error, no need to mess with done()

nb: so, thank you for the bugs :) the code is still pre-alpha really, mostly a POC to prove that the damn idea is possible. hence all the shortcuts and bugs. I do plan on making this 'prod-ready' though, and appreciate the help! I'll make issues for the 'tasks' I see coming up in the next few days, will ping when it's substantial.

threepointone / rakt

Initial feedback #6