Post

Context's are a symptom of too much knowledge of naming is required up front to start a completely new project. Consider `mix phx.gen.html Accounts User users name:string age:integer`—Rails is `rails g resource User name:string age:integer`. Rails namespace is implicit, so I don't have to think.

I don't mind LiveView being outside Phoenix, but we urgently need multi-package search in hexdocs (mentioned few time by Jose that it's coming). I find contexts great, but that might be just scars from fat controllers, fat models, fat service objects, fat classes... fat... from Rails.

I started to solve with with the Alpha project but have paused work on it until I release 0.4 of LVN. The phx.new generated app is just two people's opinion on how to structure your app. I agree that it has become esoteric and unapproachable for beginniners. Alpha will address this.

The whole idea that Phoenix leaned into *Erlang* project structure conventions is just nuts. Why go from mimincing one of the most successful frameworks in history to now leaning into one that has struggled for adoption over three decades is mind boggling.

Wait, what's Alpha project?

Great post, i can relate as a beginner with Phoenix inherent complexity. But i think it worth it to learn to organize your project right even if it is a mess at the beginning The alternative is to teach people a dummy phoenix for toy apps and then have to learn the right way in a real app.

I prefer the pain first. "Hard things first"

This works sometimes, but most of the time you don’t know what you don’t know, so to speak. Get stuff done first, make it easy to refactor and tidy up later when you know more.

It doesn't change the fact that there's room for improvement but to do this we need open and collaborative leadership. Like I mentioned in the quoted thread - I'm even happy to help but I don't wanna end up going against the grain *again* 🤣 (2/2)

Its just a tiring debate for the team lol. Before contexts: "We need structure! We need Patterns! How do we use phoenix??" After contexts: "This structure is too much!" Internal debate has been "we can't architect people's projects! People need to think! Modules and Functions is it!"

Yeah I get it but I believe it can be addressed by simply introducing basic conventions for your typical CRUD app. It's all it takes to get people started with some level of clarity. I'm not sure how contexts structure is "too much" though 🙃

I feel that recent shift from views to components does similar thing. I still cannot fully comprehend how I should handle JSON-only routes with that approach or how I should handle routes that return different format depending on the `Accept` header or URL extension.

kobrakai.de/kolumne/data... This lays out the changes for people coming from the old format. The "handle different data formats in the same module" portion simply doesn't exist in the default boilerplate anymore – there's now a format per module separation.

JSON only routes should really be simpler today, because all that changed is removing phoenix specific helpers with plain elixir.

What's the shift from views to components? Are you talking about moving from regular heex views to LiveView views?

hexdocs.pm/phoenix_view... about that. I understand a little what they mean there, but the documentation of that is so poor that I believe that most of the newcomers will just say "f… that shit" and will go somewhere else. The recent drifts in Phoenix are quite putting off.