Future of Pods?

[mehulkar]

After Colocated Component Templates (in 3.13), the motivation to keep Pods seems pretty low. I don't see a good reason for Ember CLI to keep supporting this out of box (other than that some of those who already use it, like it)

[NullVoxPopuli]

I think we should deprecate pods. Ecosystem tooling has already implicitly made their stance as well. 🙃

[rwjblue]

Ya, seems fine to deprecate, but I personally would like to solve colocation for route templates before issuing deprecations.

[webark]

Could this be something that would be good to be tied to the embroider release?

[webark]

and coming from someone who has used pods almost exclusively since the beginning, having components be able to nested alongside routes has been helpful for me and my teams. It would be nice to maintain that functionality which was an original feature of MU.

[mehulkar]

having components be able to nested alongside routes has been helpful for me and my teams

@webark this does seem nice, we use rough namespacing where it matters for this. is the benefit to be able to route split better? or is it better for team communication? something else?

I personally would like to solve colocation for route templates before issuing deprecations.

couple things to research:

• can pods functionality be entirely moved out into a different resolver and passed into the App instance?
• is colocating route templates achievable without invoking the messy controller+query params conversation? (and if so, is it good enough to colocate templates+routes and leave controllers where they are?)

[mehulkar]

and coming from someone who has used pods almost exclusively since the beginning

how often do you run into problems or inconveniences? doesn't debugging everything become way harder?

[webark]

More just for team communication and organizational patterns. There are just some components that are only useful in certain contexts, where as others are more broadly useful.

I think making the resolver more flexible to be easily extended would be great, be this through just better documentation or more exposer and stabilization of the internal apis. (moving to a non resolver api i think is nice, but here is not the place for that convo)

I see a lot of value co locating controllers and routes, as well as route templates. route templates being colocated with only routes, but can be disorientating when looking for functionality when trying they are so closely coupled to the controllers.

[webark]

how often do you run into problems or inconveniences? doesn't debugging everything become way harder?

We've never ran into issues. Sometimes there has been issues with addons, but we just always do the app reexporting as classical to avoid any issues.

There is the odd thing where you can repurpose route templates as components.. which was used once by someone who saw it as a clever solution, but just leads to confusion.. It was an easy redactor though.

[mehulkar]

Good to know. I see questions on discourse about folks using pods and I never try to help because I never know if it could be a pod-specific issue. That might be another benefit of pushing pods resolution to user land... more easy to isolate issues?

[webark]

agree whole heartedly that it should be a user land feature.

Whenever i have looked into (and the few times i have) extending the resolver, documentation and public surface is light. Would be nice for these to be beefed up to allow for pushing more to "user land" and aid in experimentation.

[timiyay]

Our company also uses pods, and we enjoy them.

Having all related files grouped into a single folder really eases the navigational burdens of Ember projects. We've also amplified those benefits recently, customising our build to support co-located tests of all types within pod directories.

I don't see a good reason for Ember CLI to keep supporting this out of box

Migrating away from pods would be a reasonably big deal for us, quite disruptive. It would be a breaking change, no doubt about it.

So the good reasons would be:

• Ember project layout is sprawling, and confusing for newcomers,
• removing support would cause breaking changes in all pod-based projects

Would it be fair to assume that, if pods support is dropped from the core libraries, that wouldn't occur until a major version release like Ember 4.0?

[mehulkar]

Would it be fair to assume that, if pods support is dropped from the core libraries, that wouldn't occur until a major version release like Ember 4.0?

yes

[webark]

and @timiyay @mehulkar I would like to say a prerequisite would be an addon that is able to extend the existing resolver using public apis.
Without this, another burden would be placed on several companies, which would just delay upgrading and adoption.

[mehulkar]

not an addon, just ember-pod-resolver (like ember-resolver), probably

[webark]

I'd be fine with manually needing to import it and use that instead of the defaultly scaffolded one..

It would have to support pods, classical, and colocated though.. as many apps have a combination (esspesially when you bring addons into account, and how they are included).

(I'm still kind of most in favor of a "resolver less" model.. but template imports are needed for that. And having the convention helps coming into a new project and solves needless discussions)

[mydea]

We use a mix of co-location for components & pods for route/controller/template sets. To be honest, I find the default setup to have route/template/components in different folders very unergonomic. I would not be happy to have pods dropped and be forced to use it instead. We don't really have any issues with pods, they work just fine for us.

[mupkoo]

I am on the same page with @mydea. Most of the apps that we have use pods for route/controller/template and I find this setup much better than putting them into different folders. But for everything else, I prefer to have them in separate folders, like models and components 🤷‍♂️

[tleperou]

I do agree witth @rwjblue, collocation route template seems to me a prerequis for a gently drop of POD.

So far as I know, Octane with Embroider does not support route-based code splitting while using POD.

[timiyay]

The potential benefits of Embroider would be the major motivation for us to abandon pods, and a powerful one.

If that project lands, and unlocks the benefits available to the wider JS build ecosystem (like route splitting and tree shaking and whatnot), it would make pod deprecation much more palatable.

[mydea]

To maybe clarify my comment above, we use pods for route/controller/templates only, not for other code like utils, models, etc. So basically, I agree with @rwjblue - if we'd have a way to somehow co-locate route/controller/templates, then we'd gladly drop pods.

[webark]

Oh, yes. We don't use pods for models, services, adapters, utils, serializers or anything like that.

[mehulkar]

Sectioning off #651 discussion

[timiyay]

We do use pods for almost all types - serializers, services, models, etc. The exception appears to be utils. AFAIK our choices were made for us by ember generate.

Example:

app
|- application
|  | - adapter.js
|  | - controller.js
|  | - route.js
|  | - template.hbs
|
|- dashboard
|  |- route.js
|  |- template.hbs
|
|- session
|  |- service.js
|
|- user
|  |- model.js
|
|- utils
   |- foo.js

Other exceptions I'm seeing - again, based on ember generate - are instance-initializers and initializers.

[jelhan]

We also use pods for routes, controllers and templates at work. It ended up with a mixture of pod and classic. We noticed that it's very easy to either miss or wrongly add the pod flag. And it's hard to teach new developers as it's not well documented. We decided to use component colocation as a chance to get rid of that mess for components. We also want to drop all usage of pods in mid-term and stay with the defaults. We hope for colocation of routes, controllers and templates but would not wait for it. What is holding us back is missing codemod and missing time to write one ourselves.

Having strong conventions is a huge advantage of Ember. For some historical reasons we invented four different ways to organize files: classic, pods, module unification and component colocation. I think it's time to settle on a shared solution again.

Maybe provide some low-level APIs to alliw experiments with other file system layouts in userland.

[michaelrkn]

Ya, seems fine to deprecate, but I personally would like to solve colocation for route templates before issuing deprecations.

Won't rendering components from routes (#641, #499, #510) give a path forward on this?

[webark]

@michaelrkn Yes, but I don't see that landing before a 4.0 release.

[michaelrkn]

@michaelrkn Yes, but I don't see that landing before a 4.0 release.

Oh, why's that @webark? The APIs being proposed seem to me to be additive.

[webark]

I guess it's just a "fool me once" type of thing, and hearing about "routable components" are just around the corner for the past 5 years. I'm all in favor of the approaches outlined though, and hope i am wrong and it comes sooner then later.

[NullVoxPopuli]

Who keeps saying routeable components are happening o.o

[wagenet]

I'm closing this due to inactivity. This doesn't mean that the idea presented here is invalid, but that, unfortunately, nobody has taken the effort to spearhead it and bring it to completion. Please feel free to advocate for it if you believe that this is still worth pursuing. Thanks!