-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nested routing support #20
Comments
Hi @rjharmon , thank you very much for the feedback! Rekit uses react-router's JavaScript API to define routing rules, so it has supported nested routing by default: https://github.com/ReactTraining/react-router/blob/master/docs/guides/RouteConfiguration.md . It should also with lazy load by Webpack's code splitting. For example, in home/route.js you could have below definition to support nested routes: export default {
path: '',
name: 'Home',
childRoutes: [
{ path: 'home', name: 'Home page', component: HomePage, isIndex: true },
{ path: 'about', childRoutes: [
{ path: 'us', component: AboutUs },
{ path: 'help', component: HelpPage },
] },
],
}; For nested features it looks good to me too but I'm afraid it will add too much complexity to either Rekit or the created application. Instead I'm thinking about to support grouping components/actions into different folders. Currently it only supports flat files by Rekit tools. And since you are trying Rekit (I'm very glad to know that) I want to share my current work on Rekit 2.0: It will allow to rename Rekit elements such as components, actions, features etc. It will provide Web UI named I think with these changes there will be less concepts and more consistence. If you want to have an early look at Rekit 2.0, you could visit: https://github.com/supnate/rekit-portal . It is a web application created by Rekit itself to mange a Rekit project. By looking at Hope you will enjoy Rekit 2.0:-) And thanks again for sharing your thoughts with me. |
hey, that's pretty cool-looking. Looks like the dependency on refactor may need freshening in rekit-core maybe? getFeatureStructure doesn't seem to be available for api/fetchProjectData.js. Also:
|
It seems rekit-core@2.0-alpha.5 was not published successfully.
You can get to know Then you could use the local rekit-core project, it should then work. Good luck! |
Thanks, will check it out. Here is a little more on my line of implementation thinking for nested features:
Probably there are other issues besides the route-creation sequence that are not as easy to adjust - input is welcome. |
Thanks for you proposes. Look good to me, especially NO 4, renaming BTW, I just realized the it's a syntax error for you to run rekit portal. You are using node v4.x which doesn't support |
Yeah, it was a node version issue, since fixed. Thanks for the tech support. :/ Hah, I hesitated to suggest renaming features/ to app/, even with a compatibility symlink. I'd be happy to contribute to a possible change. I'd like to get a sense of what other (non-routing) concerns are likely to be troublesome. |
haha, you are maybe the first 'lucky' guy to see a running rekit-portal:-P Currently I would like to put releasing Rekit 2.0 at the first priority. So that we could hear more feedbacks about whether nested features are also needed by most people. My concern is still it will add complexities to both Rekit and applications sides. Forcing a flat structure makes project easy to understand in my opinion. If it's heavily required, I can add it in the next major release. Actually the requirement from you is more like a nested routing support. And thanks for your willing to contribute, you may check out rekit-core to understand the system, and understand why nested features are complicated (for now I feel the key reason is just it adds more patterns for auto detect project folder structure), it provides core APIs for managing a Rekit project. |
BTW... I guess you can't expand project explorer tree... It's caused by
if (children && (children.type && children.type.isTreeNode || Array.isArray(children) && children.every(function (item) {
return item.type && item.type.isTreeNode;
}))) { Then re-run rekit-portal. |
Is it normal for fetchProjectData to have item.file containing a full path (from node's perspective) of a component's (etc) source file? I'd figure it would be specified as URL-relative, but then I was fiddling with rekit-core. Being that I'm running Windows, that might play into it too.. Will do more troubleshooting, but thought I'd check with you |
And yes, I did get the browser app working, with the file list and graphic. That's pretty sweet, though I admit it's a bit confusing sharing the same application space with the application you're using to visualize and control the application space. Inception, like. I dig how you're structurally manipulating the source code in response to application metadata changes. |
Yeah, since Rekit portal is also a Rekit app, it could be managed by itself. It auto detects the project where it's running so it will mange a normal Rekit app which will depends on Rekit portal when 2.0 is final released. Currently you could change Such as:
|
And I've not run Rekit on windows for long, so there may be some issues. |
src\features\rekit-tools\BuildPage.js seems like the format that the feature's 'file' wants to be in, but haven't traced down the code that is supposed be responsible for generating it that way, or at least not yet. |
Sorry that I don't understand the question... However I just deployed a demo on Heroku: https://rekit-portal.herokuapp.com/ You may want to check it. The demo app has not intended to be public for now, but you can just try it. It will be in readonly mode later so don't delete or rename elements so that I can show it to other early adopters. |
OK, from your app, the project-info API call is returning an entry 'misc', along with other entries, all of whose 'file' entries include /app/src/ ...
I'd hope for those paths to be relative to the app dir (such as "src/features/home/images"), so that the client-side code doesn't have to munge the path to get rid of the app-root (/app/, here; "c:\Users\rjharmon\dev\react-portal", in my case). I think the URL encoding of : or \ is preventing that correct removal for me. It's quite tangential to this issue #20, though. I'll make a separate ticket if needed. |
Thanks for the investigation. Using full path is convenient in many places for |
I'd suggest using https://github.com/kamicane/pathogen or another utility to more easily work with paths. I understand dealing consistently with pathnames is a convenience, but using full host path names is also a security risk. For example of how this can be used to an attacker's advantage, try this from your browser console from your demo site:
Recommended: normalize all paths so that they're project-root relative, deal consistently with them in that form; reform full system paths with the project-root only when it's required. |
Thanks for the reminding about security risk! That really makes sense. I thought rekit-portal always runs on local machine but if others know the ip it's really put user under risk. I will review the middleware API to prevent reading arbitrary files. Using relative paths doesn't help because rekit-portal needs project root path to display to the user. I will also look at normalizing paths later. Thanks for the recommendation. |
Reopen for tracking fullpath issue. |
Fixed the security issue of fetching file content api by restrict the full path to start with the project root path. |
In the current rekit architecture, a feature provides only a single layer of routing; common/routeConfig.js combines a flat set of feature routes. Naturally, pages do not have nested routes.
For a complex application, Rekit's modularized approach on managing components and containers is really helpful. If features could be more naturally nested, it would really help managing bigger applications. I imagine features/home/all-about-us/ having a variety of pages, with the routes being nested under the home router. Ideally, those nested routes are lazy-loaded with react-router's getComponent() and webpack's code splitting
@supnate have you done any design thinking along that line?
The text was updated successfully, but these errors were encountered: