rekit
rekit copied to clipboard
supnate
Rekit with next.js?
Do you think it would be possible to combine Rekit with next.js (React SSR framework)?
It might be difficult because both Rekit and next.js are "opinionated" about application structure, but I'm curious. If there's interest in this, but you don't have enough time, then I might volunteer to do some research.
Hi @leob , thanks for the suggestion. I think the answer is yes though I've not used next.js. Rekit should be able to work with next.js because it is just an app created by create-react-app but with a special folder structure.
I would definitely appreciate it If you would like to do some research on this!
Okay thanks for the feedback!
Yes, my intuition is that it should be possible, but it would definitely be interesting to research this. You've written an article explaining how to 'port' an existing React app to the Rekit structure, so let me take that as a starting point.
(I was also contemplating if the Rekit "feature" concept would be doable in Vue.js, a 'Vuekit' if you will ... and Vue has its own next.js which is called nuxt.js ... but that's for later)
Leave this issue open and I'll have a look at it.
Well, I looked at Next.js but integrating it with Rekit will be very difficult, because:
-
It uses its own tooling to set up Webpack, HMR and so on (with specific versions of Babel, Webpack etc - which next.js might depend on for correct functioning)
-
It uses its own, highly opinionated application structure - your pages must be in a "pages" directory, and so on
It's easy to predict that this will clash with Rekit's structure and tooling.
A better option for integrating SSR into Rekit would be something less opinionated and less "invasive" such as Razzle (https://github.com/jaredpalmer/razzle), see an example here:
https://www.npmjs.com/package/razzle-examples-you-may-not-need-next-js
I give this a much higher chance of successful integration with Rekit because it does not dictate application structure.
Might have a look at it when I have some time.
Thank you very much for the meaningful findings @leob ! Really appreciate that you did what you said.
For #1 issue: Rekit doesn't depends on any opinionated configuration for webpack or babel. If needs to support Next.js, we can create a new boilerplate project for it rather than the current CRA one. So the command maybe: rekit create my-next-app --template nextjs . To do that you can refer to the article: https://medium.com/@nate_wang/using-rekit-studio-in-an-existing-react-project-39713d9667b
For #2 issue: it looks like a really difficult part to integrate next.js to Rekit. A naive idea in my mind is that we create a pages folder which contains component wrappers from features, they are only used by nextjs and the code pattern is fixed, like:
import { MyPage } from '../features/home';
export default (props) => <MyPage {...props} />;
We can create a Rekit plugin to auto generate this file when creating/moving/deleting a component.
However I've not used nextjs before, don't know if this is a possible approach. I will take a look at nextjs too. Thanks again!
Yes, your idea of creating wrappers for the pages might work, good one.
Well anyway, I'm spending a few days looking at next.js to see if I like it and if it is worth it.
The premise of next.js is "make React simple" (simple as in, creating pages with PHP). And indeed, to create a "Hello World" app with next.js takes 2 minutes and is insanely simple (the same goes for Rekit I think).
However my observation is that, while next.js makes the simple tasks very simple, this simplicity quickly disappears when you try to do anything a bit more complicated or less 'standard' ... for instance it uses its own routing system (not React-Router) and it's totally not obvious how to do for instance authentication (protecting a subset of your pages), I've spent an hour googling for a sensible and not too complicated approach, finally found something I think.
To be honest SSR makes a lot of things way more complicated and I'm still not sure if it's really worth it for my app. Further complication is that I'm using FeathersJS for the backend and that has its own way of doing things (based on Express.js but a little different), I'm now trying to figure out if I can integrate next.js with FeathersJS, especially authentication is going to be challenging.
SSR can also be heavier on the server, and next.js with React and so on is not exactly a tiny download either (and great performance is not automatically guaranteed).
A good thing of SSR is that (probably) server side rendering might make it easier to integrate an existing piece of code (page) which heavily uses D3.js and some legacy client stuff. I suppose SSR will make it easier to pull that into the app which might be problematic with client side only React.
If I can't get a basic version working today then I'm going to push next.js aside and just go with client side only React for now, and then I'll probably look at Rekit (and try Bulma for the CSS/styling). Do you have a good 'standard' solution for authentication? Probably quite easy to do with react-router. If I can integrate Rekit with Feathers then I'll open source it.
A final option would be to use Vue.js instead of React. Vue.js is nice but I don't want to give up completely on React because I like it a lot too.
But in the end I don't want to spend a week just on the plumbing of my app, in a few days I want to start developing functionality for my customer. But getting to know a bit about next.js does not seem a waste of time, and then I could try to figure out if it could be possible to integrate it with Rekit. Or alternatively we might look at Razzle.
Thanks for sharing this. To my understanding SSR is useful when 1) first-page load speed is very important 2) SEO friendly is must have for the app. But I don't know why it helps to reuse existing legacy code.
For auth with routing, I think it's very simple in Rekit because it uses only JavaScript to define rules and all rules are defined in dedicated config files. For example, to redirect all pages to "Login" if not logined, you can just edit src/common/routerConfig.js. The tricky thing is you need to change the module export to a function so that you could return different routing rules based on the current auth state.
Yes it would be beneficial for those two cases. I think people often reach for SSR if they're building an app with characteristics of a 'classical' website (content heavy) but they still want to benefit from the advantages of a modern framework like React (or Vue). It's sort of a hybrid between SPA and server generated pages.
The reason why I thought next.js or SSR in general might help with integrating that "legacy page" I was talking about (well it's not really legacy, the point is it is D3 which I'm not sure is easy to integrate with React) is because you can selectively perform server side rendering of pages.
Also these features might be helpful (but I'm just guessing):
https://github.com/zeit/next.js/#multi-zones https://github.com/zeit/next.js/#automatic-code-splitting
But I should do a quick test to verify this. If I can't get this to work then I might conclude that SSR isn't really worth the extra complexity for my project.
I think it's easy to use D3 directly with React just as how I do in Rekit Studio. For example: http://demo.rekit.org/element/src%2Ffeatures%2Fdiagram%2FElementDiagram.js/code
It's used to show an element's dependency graph.
Looks great! Rekit Studio looks surprisingly much like VSCode, very slick (well VSCode is also a web app under the hood, just packaged in Electron).
The point with my "legacy" D3 page is that another developer made it, and I don't have any direct control over it. Theoretically I can modify the source a bit but only to a limited extent because I have to "redo" my changes anytime when the dev delivers a new version. And the code is really complicated, I know nothing about D3 and the code looks like abacadabra to be, I don't want to mess with it.
I thought server side rendering might make it easier to integrate that code without changing it, I suppose this was one of my main motivations to get interested in next.js. But I'm amazed at how much extra complexity it adds to the app, I have serious doubts if it's worth it.
I'll play a bit with it today, but I have the feeling that maybe it's a bridge too far and I'd be better off with a solution like Rekit or Vue.js (both look good to me).
Anyway I can still spend a few hours on next.js, I'm intrigued enough to investigate it a bit more.
Okay, just when I had the feeling I'd better give up on next.js (way too complicated) I got it working with authentication against a FeathersJS backend, that's better than I expected and in the end it wasn't that complicated ... next thing I'm gonna try is integrate the "legacy" D3 page, if that all works then I'd like to give it a shot to try a Rekit integration ...
Yes the next step would be integrating that legacy page (and 'proving' that it cannot be done without SSR), this would justify the time that I've spent on it. Well I've learned a few things, and I've refreshed my React knowledge, which was a bit rusty because I've mostly been doing Vue recently.
But if I look at the amount of complexity that SSR adds to an app, and the heavier demands it makes on your server infrastructure, then I think this is certainly not for the majority of apps. The fact that you again need to think/worry about server rendering seems a step back, you lose the simplicity of the "SPA + API" model.
The more I read about it (and about the potential complications it brings, for instance correctly "isolating" user sessions from each other, which is trivial with a client-only solution), the less I like it. I see too many people complaining that they "have to" use it (for instance because the boss says so) but that it's quite painful and that they don't really like it.
So I'm probably going to forget about this "feature request", and focus instead on sorting out how to integrate Rekit with Feathers (which I expect to be easy).
I've been working with nextjs the past 2 years or so.
The only thing you need for it to work is a page folder that exports a react component and your nextjs/react/react-dom packages. All the configurations for nextjs are under the hood (you could still create custom webpack and babel configs though).
I have no clue how rekit works but I would totally love the integration of nextjs and typescript. @leob if you have any questions let me know to see if I can help you.
Also, the wrap around the page files could be a solution but that's where nextjs does the SSR code by calling getInitialProps (which might be also a good place to do you authentication checks for 302 redirects and what not).
Also, getInitialProps only gets executed once in the server side when you access the app for the first time, after you go browsing around the app, it will be executed client side.
Would have to look at how Rekit structures things, at the moment I know a bit more about next.js than about Rekit ... Typescript is a completely different story, haven't used Typescript at all yet. I've worked at integrating next.js with a FeathersJS backend, got that working in the end.
Hello there, hope you're all well! Was there any developments on this? I see the last message was sent 5 years ago but I would love to see Rekit work with NextJS. Have a great weekend guys!
Hello there, hope you're all well! Was there any developments on this? I see the last message was sent 5 years ago but I would love to see Rekit work with NextJS. Have a great weekend guys!
Project seems to be "dead" ... ? No activity, as far as I can see ... correct me if I'm wrong :)