Post

I don't think it's just contexts' fault. I think it's also too much boilerplate that's needed to achieve basic stuff and LiveView not being part of the framework + its design with views and components being two different things. It's still the best stack on the planet if you asked me 🙃 (1/2)

George Millo@georgemillo.bsky.social

Did contexts kill Phoenix? New blog post: arrowsmithlabs.com/blog/did-con...

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.

kobrakai.deData to ResponsesPhoenix 1.7's HEEx introduces new HTML rendering patterns, but under the hood, much remains unchanged—understanding these lower-level primitives clarifies how data becomes HTTP responses.

Yeah, but when I want to migrate I always forgot about all that and I am frustrated all over again.

0 reposts0 likes

There's no need to migrate though. I'm still maintaining a project, which started in 2017 and phoenix has never been a problem. I'd like to migrate eventually, because I find the newer approaches and APIs better (there's less magic overall), but that's on me.