-
Notifications
You must be signed in to change notification settings - Fork 50
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
What about directory structure? #3
Comments
oh yes. |
Hope this is answered :) |
Yes is it, sort of :)
imho better is feature-based structure:
and I'm afraid that Mantra will use first approach and that's kind of worries me :/ |
That's something we need to figure out first. We'll go with 1 for now. But that's not coming with the initial draft. We'll have it. |
+1 for the feature-based structure. I think it's a better way of laying out larger projects, and more in line with the react methodology of grouping feature based code together. |
@arunoda you can maybe reopen this issue to get more opinions from people |
@achtan That's a good idea. |
Feature-based 👍 |
+1 for Feature based. |
+1 for Feature based |
+1 I think it'll be easier to understand logic & testing flow if everything is feature-based |
+1 for Featured based. Agreed. Feature-based is probably better for scalability. I used to use a type-based structure, but an app quickly grows in size and you end up having these huge folders filled with many many files. |
I'm looking to work on the module system. So here's my idea. In a module, we can have it's own
But only containers and components can be only view to the outside. (Or do we need actions too?) If it's a one module we can have a directory structure like this:
Otherwise, thing will get a bit complicated. What do you think? |
One issue that I've had in virtually every framework is how difficult it can be to stay organized when grouping code into single file compartments (e.g., 'actions.js'). My favorite solution to this so far is to turn those files into directories, and inside the directories house a file for each instance. Taking actions as an example, rather than adding all of the actions for the module into a single file, I would have an actions directory, and each action itself would get a file inside of this directory. This makes it easy to find code you're looking for, makes each file less complicated, and clearly spells out the requirements of each action via imports (if imports are used rather than a global namespace, which seems to be Meteor's preference). With this in mind, my ideal module would be laid out as follows:
The tests directory is kind of up in the air. I feel like it should be broken down, but I don't know enough about the proposed testing structure and usage to recommend if it should be or not for this use case. |
Very similar to the two above comments, I have a idea writing in this Gist: https://gist.github.com/minfawang/12ca72ac36260426e46b Within each module/feature, I have "containers, components, actions ...", but rather than just name them as "container.js", "component.jsx", etc, I put them into separate sub-directories. Then each sub-directory has the "index.js" that exports the files/functions/object/anything dependent by other files/modules. So we could still do something like |
+1 for the feature based structure recommended by natecox. |
@natecox and @minfawang your proposals are type-based in context of module... @arunoda agree with you, that's a good direction! |
@achtan Oh my bad.. Sorry for not reading the post carefully. Now I see your point. I think both approaches have its own advantages. For the "one module" approach proposed by @arunoda I think the root directory can get cumbersome when the app grows to a large scale. I feel actually my approach could be thought as feature and type combined based if you separate modules based on features. Currently I separate modules as different code splitting points. You can think of a module as one big feature or a set of small features. |
@achtan This was within the given context of 'structure inside a module'. If you assume that modules are based on features, than this would definitely be feature based rather than type based. Type based would be
where we're suggesting
|
@arunoda One thing I noticed while reading the spec is that the suggestion is to put all of your components inside the |
With larger apps, things tend to get complicated very fast. Files get bloated quickly, and I always feel like I want to make many smaller components rather than fewer larger ones. What do you guys think about modules with sub-modules approach?
|
@adrianmc I think we should limit to a single level of modules. Otherwise, we'll have a lot of nested modules and very hard to deal with. |
@adrianmc I feel like submodules make it too easy to violate the single responsibility principle. |
@natecox if you isolate this one:
it is type base structure inside module because you separating code by type |
maybe a good question would by "what is the 'Module' and what you / I / everyone think under that term" |
@tomitrescak In Meteor everything in the server got imported (or places outside imports). Let's see what we can do for that as well. |
@tomitrescak everything in the client also gets imported, if they aren't placed inside |
@arunoda and everyone, I did a modified structure of Mantra to test my point
I would like to get your opinions about it: https://github.com/tjmonsi/mantra-atomic-structure-suggestion |
Guys, We are finalizing the module system and now it's almost ready. But, we need to figure out a decision regarding routes. Could you have a look at this? |
@arunoda Could you explain why you prefer to restrict Mantra modules to being client side only? It seems to me that a “module per feature” model would benefit from Meteor-like “universal” modules. |
In the future, there won't be any server code we need to manage. (Or we don't need to). So, mixing server and client code together is a really bad idea. |
I disagree in that I see some value in modules being able to define some client and server logic. A central argument in your article against “universal apps” is against “single codebase that runs everywhere” which is really not my point here. Similarly I could agree with “mixing server and client code together is a really bad idea”, but this is easily solved by putting code for different targets in different files. So maybe we don’t have the same definition of a module, but for me it is important that they are able to send emails, define new GraphQL mutations, or start backgrounds tasks, all of which happen on the server. I can go into more details if the examples I’m giving aren’t clear (and if you have some time you can take a quick look into a description of my desired plugin system for Wekan). |
I always though about universal apps as client code running everywhere. Is clarifying to read about universal apps as code shared between client and server too, seeing them mixed and loaded twice (in the browser and in the Node) was something that really bugged me on my way learning Meteor. On the other hand, I think that this is one of the Meteor core ideas. If I start to think in server and client code separated, glued by something like GraphQL I don't know why I even will be using Meteor instead of a Node/Express solution like Relay or my own. Splitting server and client code and not thinking universally isn't Meteor-counter productive? Why to use Meteor if you will be avoiding Meteor features? |
@leocavalcante this is a core principle of mantra, so it will never change. I do think it was one of Meteor's core ideas, but I think even MDG is moving away from this practice as it doesn't work in the long term. Think of React/frontend as just the view layer, as it is. Then Meteor/server as the backend/API that is called. The two aren't and really shouldn't be related. Arunoda's article on this sums it up pretty nicely. It's a different way & a change to what we've been taught with Meteor. And if you don't like it, you don't have to follow it :) |
Thanks @markoshust |
i'm kinda agree with @mquandalle |
I think for me, if you are creating something that will be put in the If you are going to put the modules folder inside the import, then i guess And from there, you can publish it to npm, which is akin to just putting On Tue, 2 Feb 2016 04:49 David Ďurika notifications@github.com wrote:
|
I really don't like this idea of separating client code from server code when we are dealing with JS 😬 This reminds me so much of bad practices: code rewriting, mixed responsibility, team shouting match, project management euphoria... This clearly defeats the whole purpose of using a common language on the server as well as on every clients. Yerk. For dealing with different targets and bringing more stuff on the table for capable devices, we should use coding/design patters. AOP, for instance or simple directive. There's not 1k flavors per device for each Linux kernel release. Though you can install it on almost every iot, smartphone, computer, server, grid and even fridge. They are using simple pragma and macro. Just like we can do it with UglifyJS or SweetJS. |
@pem with respect, most of the problems you're addressing are almost certainly the result of tightly coupling the server with the client. By drawing a distinction between the code which operates the server, and the code which powers the client, you are actually allowing for a much greater freedom of mobility in your code, and dramatically reducing boilerplate code and rewrites on large projects. You are allowing yourself the freedom to have your server power your web app, native apps, et cetera without bloating each client's install with the specific needs of a release candidate. Meteor has always had a clear distinction between client and server at this point, which was muddled only by documentation. For example: What mantra is doing is drawing a clear philosophical distinction, rather than simply a technical one. |
@natecox And nope, this is not an issue with tight coupling. On the contrary. Splitting client and server code is like claiming that HTML / JS and CSS have been created for avoiding coupling. In the end, we all know where it ends. That the core essence of React 😄 I strongly prefer the isomorphic approach where you develop a use case from end to end. It's far clearer. For instance, I can tell you that being able to make a whole payment process in a single module is amazingly productive and clear. It would be mumbo jumbo splitting into modules for the client A, the client B, the server, the shared parts... blablabla. |
@pem What you're describing is monolithic, rather than isomorphic. Isomorphism simply describes that all of the app assets are written in a single language. The dichotomy here is between modularity and monolithism. I would content that writing monolithic apps decreases clarity, understanding and therefor productivity by eschewing the single purpose principle. Instead of focusing on doing a single thing and doing it well, you're focusing on doing everything in the same spot. This leads to unrelated code being colocated, a more complicated structure and less ease in perusing code. How this comes up in the code itself is a grab-bag. I feel that a strong separation of client and server is a good thing, but I also think it can be represented in multiple ways. A strong feature-oriented modularity in the total app itself goes a long ways, and I personally feel that including a As a side note: |
@natecox Well, it's a point of view. I strongly prefer the use case view. It's more natural for my flow of programming. The framework should make the effort of reusing, splitting, optimizing. We could just put stuff for orienting it like we do with |
@pem everyone is entitled to their point of view, of course. There's more than one way to do everything in programming. That being said, Mantra has clearly established itself in the camp of modular, non-universal, opinionated architecture. It's probably not what everyone wants from Meteor, but just taking a look at this repo over the past several weeks I'm convinced that there are lots of us who agree with it and I wouldn't suggest that we change fundamentally to try to please everyone's point of view. There were a few things in the making that I didn't initially agree with either, but keeping an open mind and being willing to explore them I have generally reversed those opinions. |
Hello Arunoda,
need to take some decisions where not everyone agrees.
Reply to this email directly or view it on GitHub. |
Hi all, I'm happy to close this issue after some great work. Now we've a module system as we discuss.
|
Sorry @arunoda but I still can’t understand your reasoning about modules being unable to define features for the server. Your sample application for instance has a module called “comments”. On the client, the stub methods are defined inside the module whereas the corresponding real methods are defined in the global context outside the module on the server. I would totally buy that this inconsistent architecture between the client and the server is due to some technical limitations of the Meteor bundler. Meteor indeed doesn’t offer much control about where we put files and I would agree that for now it is easier to put everything that is related to the server on a |
@mquandalle Shall we open a new issue for this? |
@arunoda do you have examples for how to distribute modules via npm? |
@tonyxiao not yet public. Only think I'm finding hard to do it the CSS packaging. If that's done, we are good to go. |
Inline styling ? I like the "CSSmodules" specs... |
Will be Mantra opinionated about directory structure?
The text was updated successfully, but these errors were encountered: