-
Notifications
You must be signed in to change notification settings - Fork 4
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
relative locals #26
Comments
+1 to i think having too many |
I've always wanted |
implied path is cool idea. too bad implying |
yeah more than one lookup path sucks haha, i think more than one level of nesting in any application is an anti-pattern |
i'm pretty confused now because you are guys are just calling things anti patterns without thorough explanations. hate when this stuff happens on twitter. i agree that something like however, i don't see how this relates to paths. i would consider this good structure:
since you're separating logic from presentation, but you'll need a lot of paths/locals magic here. i think it'll be better if we can do now, are we talking about something else? what exact structure do you consider an anti pattern? |
I'd disagree about it being better than naming things "people-model". That's exactly what it should be named because that describes t perfectly. We made this mistake and one of my next tasks is to rename them all to make it more clear. But also i agree with TJ that having more lookup paths than a single "./lib" folder is usually bad. (Obviously "./components" excluded.) We also used to do this, and it just gets too magicky for everyone else reading to have to look through all the component.jsons to figure out what's happening. The "downside" people bring up of havin a huge lib folder is nowhere near the downside of having too many folders in terms of maintenance. The other thing were doing now is that we will only have local lib folders for individual express sub apps (one per page of the site generally). There is no common shared "./lib" among them because then you need to reach out, and none of the shared stuff will be versions, so you end up in a shit hole again. |
so you don't separate all your views from your model? that sounds terrible to me. for simple stuff that should be fine, but the "downside" is more significant to me. you're mixing your model, controllers, and views all in the same folder (though I hate those terms). i agree that multiple component paths are bad, but i disagree that multiple folders are bad. i would say having a express sub app per page is an anti pattern - you're bringing guns to knife fights. we should probably decouple views from apps in the future so you don't have to do this (or just use co-view). i think the only time you should be using sub apps is when it's actually a subapp - like mounting a blog on merchant site. so the goal of relative locals is to avoid look up paths. there will be fewer paths, which i think we all agree having more than one is generally bad. for me, more than 1 look up path is an anti-pattern on a per-component basis, but it sounds like you guys think this is true for the entire app. are we okay with this? if you do something like: {
"name": "app",
"locals": ["./client/person"]
} within @dominicbarnes what do you mean by implied path? |
@jonathanong I mean that the component root directory is always assumed to be a path to load Right now, to get your last example to work, you'd need to add |
we don't combine views and models, our directory structure would look like this:
my opinion is that paths should always be i don't think subapps is a problem, or at least i don't have enough experience yet. it's not that every page needs to be a subapp, just that like pages are combined. and in the case of marketing pages they are often unlike all the others because you want them self contained, so in some cases it does become a |
Less about app structure, more about specs. Relative locals? |
-1 because it results in a crappy app structure |
Actually, yeah. None of my arguments make sense if we just add ./ to that paths. Nice. |
ex. for boot, you would currently do:
would be nice if you could just do:
i feel like if you have too many paths, you could basically run into global conflicts. i'd like to have
model/thing
andview/thing
for example without doing component names likemodel-thing
andview-thing
.also, why is it called
local
? should belocals
since it's an array.The text was updated successfully, but these errors were encountered: