3 ms·
I tend to ignore the whole context thing in Phoenix, it confused me in the beginning when I was learning about Elixir and Phoenix. It's a design pattern instead
by POiNTx 3y ago
I tend to ignore the whole context thing in Phoenix, it confused me in the beginning when I was learning about Elixir and Phoenix. It's a design pattern instead of a core functionality of the framework.
Just think about what are good interfaces and abstractions. Seperate your core functionality from your "view" functionality as Phoenix sets it up for you anyway (App = core and AppWeb is your external view layer, being a webpage, json api, liveview, etc). You might end up with something that looks like a context and that's ok, but it shouldn't be what you start from.
- atonse 3y agoI mainly think of contexts as what the "business layer" used to be in the Java world. There's the code that maps to your databases (Ecto structs, like "User" that maps to a users table). Then there's the code that explains higher _business_ concepts, (like "register user" - which might insert a user, send an email, etc). In ruby, for example, a lot of that stuff was just combined in the same active_record classes. So you could say user.register.send_email. But now you'd do Users.register(user) and Users.send_email(). Just a different name for a pretty standard concept of separating your business level code from your objects as stored in the database.