[Branch: feature/found] Routing with Found #182
Conversation
This is great @LorbusChris! Thanks. I've been following |
@LorbusChris I see SSR landed. :) I would hold off doing any coding on this. A big update is in the pipeline which we should probably wait for before doing any more branch work. |
The Found SSR API is pretty trivial anyway (but it handles waiting for data dependencies for you!). |
@taion which is pretty darn amazing! :) |
@LorbusChris v10.0.0 is almost ready to ship. :) |
Good news first: This is working in development now. 🎉 Unfortunately in production the client is not being loaded and I'm getting this error in the node console:
If I'm not mistaken this has to do with this issue with babel-runtime: babel/#4783:. Maybe we can use babel-polyfill here for the time being? @ctrlplusb I'm not sure what your plans are in regards to branches using Found (or any other routing lib for that matter), thereby deviating from the base-stack's RRv4. In the mid-run I'm going to be steering this towards relay (with found-relay) and graphql. First, however, I'll connect this to keystone, which provides a neat admin UI and API for managing mongoose models and connecting to MongoDB or Redis. If there's any interest in a boilerplate blog/gallery implementation, I'll happily share :) FYI @taion Everyone, constructive reviews are highly appreciated! |
@@ -25,9 +30,7 @@ function renderApp(TheApp) { | |||
render( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a problem with this Promise
Yeah, it is that bug. Interesting. Pulling in the polyfill explicitly would fix things. Let's see. |
@LorbusChris great work. In terms of the branch structure I would prefer if you kept the tech stack as purely "found" for now. We could introduce extended versions of the branch that could introduce additional technologies (i.e. "relay"). :) I think have a base "found" branch will be great, as it opens itself up for solving data fetching needs for many libraries (e.g. redux). |
@taion I think the polyfill.io service allows you to specify additional flags for es6 specific features. I believe |
Try the following: <script src="https://cdn.polyfill.io/v2/polyfill.js?features=es6"></script> |
It's not an ES6 feature. It's stage 3. |
Ah oki. 😟 What is the feature? Out of interest. |
It's async iterator support – it's how Found manages displaying loading states while fetching data. |
Of course yes. Thanks. |
@taion Sorry I'm still in the unclear about this. Is this actionable and can be solved by using the polyfill right now? |
@LorbusChris Thinking about this. You may just need to add the babel async-to-generator plugin to the project. |
@ctrlplusb Thanks, I'll have a look into that! (probably not before the weekend though) Edit: Resolved merge conflict. |
I think babel-polyfill is the way to go pending the runtime fix. It's the symbol polyfill that's broken, not the transpilation. |
If this also handles data fetching and integrates with redux - how does it work with apollo/graphql? :) |
Amazing @LorbusChris!! I can't wait to try it out. Great work! |
@codepunkt maybe you could use the client-agnostic APIs of Apollo within the |
I think that's how I'd do the Apollo integration 👍 |
Hey @LorbusChris we can merge this in as soon as we do the next release from |
return <Component {...props} />; | ||
} | ||
|
||
function CodeSplitHome() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
It's nice wrapping it up like this.
@@ -125,14 +125,17 @@ export default function webpackConfigFactory(buildOptions: BuildOptions) { | |||
// This makes importing of the output module as simple as: | |||
// import server from './build/server'; | |||
index: removeEmpty([ | |||
// Required on the server to fix an issue with Found's transpilation | |||
ifNode('core-js/library/fn/symbol'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Well found! Haha, pardon the pun.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah... still need to fix this on the babel side, sigh
Really great work here @LorbusChris :) I'm excited to get this in |
@ctrlplusb very glad to hear that! :) As there's already a merge conflict with the yarn.lock file, I propose the following: When the next release is out, I'll update the FEATURE.md accordingly and rebase the branch one last time so all changes can be cleanly merged in on top of that release. Now, with you having already reviewed the PR, please do tell if you'd prefer a merger over a rebase. The diff should stay the same, though. |
Implements Client & Server Side Rendering with Found
Adds acknowledgements Improves wording
I believe this is ready to merge now 🎉 |
Let's do it! 👍😀 |
💫💥💖 |
We just need to update the feature branches doc on master now. Thanks for this @LorbusChris ! |
babel/babel#5195 would also fix the babel-runtime issue, BTW. |
Awesome news @taion Thanks for thinking of us! 🙏 |
This should work now with the new babel-runtime 6.23.0. |
Uses Found for react routing.
Implements Client & Server Side Rendering with Found.
See #182 (comment)
For now, only supports Client Server Rendering with Found.I will update this PR as soon as Found's creator @taion adds an SSR API.We can then determine, whether or not code-split-component's createRenderContext() will work without additional changes to it.
@ctrlplusb