features structure #8
Comments
|
Hey David!
Correct, the example code is not using the feature structure yet, as I'm still testing it in real-world applications before I decide if it's a flop or not. :) And no, I'm not borrowing from Mantra. I just had this idea that if I'm working on a large application, and Feature XYZ is giving me problems, it might be easier to dive into the code if everything related to XYZ is in
I feel it's a bridge as people who are used to the "globals everywhere" model of 1.2 move into 1.3 and get used to import/export. I have a feeling MDG will eventually make everything 100% explicit imports. Plus, my folder hierarchies are deep enough as it is, I didn't want to introduce yet another level! |
|
Thanks for the clarifications. Since I'm just getting into Meteor now (awesome timing, no? 😉 ), the magical, globals-everywhere approach feels way too loosey-goosey for me, so I rather liked that MDG is counseling avoiding it. I get the same feeling as you that they'll move towards an import-only approach in future versions. And btw, didn't meant to suggest you were following Mantra's philosophical approach, just the abstract notion of modularizing features. I put some good time into exploring Mantra over the last couple weeks, and in the end it seems too constraining for the sort of projects I am entertaining with Meteor. I am still a bit fuzzy on how the modular approach in your current—wip, I get it 😄—boilerplate will work with the separation between server and client; If the entire features directory is located in the root client folder, doesn't that mean all the server-specific code will get incorporated into the client as well? As a Meteor greenhorn, am I missing some important detail? |
Ha! "Pardon our dust.."
Yeah, I think I understood that. I just meant that I didn't get the idea from them—just my own private brainstorming sessions. :) My boilerplate, while evolving, can be considered complete and usable. But now I see what you're asking, about separation. The idea is to put And certainly not all features will even use a Hope that clears things up! I've also moved away from JS styles to using BEM. IMO, JS styles fall apart when you want to share common stylings among several components. I started defining object literals in other places and importing them to access styles, and it felt clunky to me. I believe CSS Modules will eventually be the landing point for React, and I think using BEM will lead to a smoother transition to that down the road. I see that Mantra took quite the opposite stance and officially recommends JS styles. :) But of course, there is no right or wrong! Use what works for you, but always keep an eye out for what other people are coming up with. This landscape is constantly evolving. PS: I'll update the example app to use BEM when I get some free time. |
Generally, the idea of features makes perfect sense. But I'm still not understanding why I'd want (potentially sensitive) server-related code to reside in a subdirectory of the client folder. That means it will get incorporated into the client code, right? Even if it is dormant, it'll still be compiled in, no?
Yeah, that was the first thing to go as I started playing with the example branch. 😃 Inline styles in javascript are a fabulous idea if I want my designers' heads to explode before they hand in resignation letters! Otherwise, my deviations from your direction so far are slight. I was already intending to use Astronomy, so was pleased to see that already in there; React and redux were on my hit-list too, so very nice. I decoupled the Redux Provider component from the layout, so I can keep alternate layouts DRY. I'm on the fence between react-komposer and react-mixin; And I'm toying with the idea of trialing react-router in place of flow-router. |
It wouldn't. The structure goes like this:
Me too, actually. Since you're not supposed to have reactive data or serious business logic in Flow Router, I'm not seeing the advantage of it anymore over React Router, which is far less verbose. But I'm still mulling over the idea of moving. |
|
Thanks for the quick responses!
Oh geez, I was misreading that structure in my tree view... heh. Even so, I thought any folder other than imports gets included in the build. If it's at the root, then its contents will get included in both client and server... From the meteor guide (1.3):
No? |
|
Correct. But.. quoting myself way above:
Just personal preference. |
|
Oh, I forgot: On the router, one other change, which I cribbed from @tomRedox's simpleCRM, and really like: // Set group for authenticated users
const authenticatedRoutes = FlowRouter.group({
name: 'authenticated',
triggersEnter: [function(context, redirect) {
// Redirect unauthed users to login page
if (!Meteor.loggingIn() && !Meteor.userId()) {
console.log('not authorized');
redirect('/login');
}
}]
});
// --- PUBLIC ROUTES ---
FlowRouter.route('/register', {
name: 'users.new',
action() {
mount(MainLayoutCtx, {
content: () => (<NewUser />)
});
}
});
FlowRouter.route('/login', {
name: 'users.login',
action() {
mount(MainLayoutCtx, {
content: () => (<Login />)
});
}
});
// --- AUTHENTICATED ROUTES ---
authenticatedRoutes.route('/logout', {
name: 'users.logout',
action() {
Meteor.logout();
FlowRouter.go('/');
}
});
authenticatedRoutes.route('/', {
name: 'items.list',
action() {
mount(MainLayoutCtx, {
content: () => (<EntryList />)
});
}
});
...I haven't looked closely enough at react-router to know how to implement the same so elegantly. |
Not to beat a dead horse, I just want to understand. In the here-and-now, this method means those files in the server directory will get incorporated on client and server, which seems wasteful of memory and bandwidth, and potentially a security issue. Or... 💡 Does Meteor exclude files from a "server" directory at any place in the hierarchy? |
|
Yeah, I like how React Router is just a handful of nested React components. Much shorter. But I don't know what the equivalent of I've seen many people recommend against this pattern, of handling authentication in Flow Router. I used to do this too. Instead, it's recommended that you handle auth and redirection in your React components.
|
|
Now if you're just talking about the build tool and efficiency.. maybe that's something to consider. I don't know. I'm gonna keep beating the drum for the removal of lazy loading.. hopefully MDG will consider it. :) I'm not really a fan, but there's no way they could just remove it in 1.3. All the projects that rely on just using magical globals would break, and it would be disaster. |
|
So, I did indeed have a fundamental misunderstanding of Meteor's build logic. I just tried including a simple console.log in a |
From the react-router tutorial docs: // Repos.js
import { browserHistory } from 'react-router'
// ...
handleSubmit(event) {
// ...
const path = `/repos/${userName}/${repo}`
browserHistory.push(path)
},
// ...or... export default React.createClass({
// ask for `router` from context
contextTypes: {
router: React.PropTypes.object
},
// ...
handleSubmit(event) {
// ...
this.context.router.push(path)
},
// ..
})
Huh, OK, thinking about it now, that starts to make sense. It's a paradigm-shift from my work with other frameworks, but it does rather make sense in React. (No need to worry about round-trips to a server for routing, the view-controller approach with React, etc.) My instinct then is to handle auth in the layout component (where we're also inserting the Redux Provider) and permissions in subsequent modules/features. This makes even more sense with react-router's nested routes, helping to keep permissions logic DRY. |
|
Quoting myself:
On second thought, that works in flow-router, where the layout decorates the route's component, but not in react-router, where (I guess) auth would have to be handled further down the hierarchy, along with permissions. 😞 Must go read and ponder more… |
|
Good luck. :) |
First, thanks for this. Of all the 1.3/react/etc boilerplates folks are putting out, Mantra included, this is coming closest to an approach that resonates for me. I also think the notion of annotating the example branch inline is brilliant. Would love to see a more comprehensive version of such an approach!
In the Readme, you mention:
The boilerplate includes an empty feature skeleton, but the example branch has no features. It looks like your approach evolved after branching the example off. Just curious what your initial thinking is here. Are you borrowing from Mantra's approach to file structure?
Lastly, any particular reason you eschewed the Meteor guide's recommendation of using a root import directory?
The text was updated successfully, but these errors were encountered: