I took some time writing down my thoughts about Contexts a little in the form of a slightly longer blog post:
Lately, there has been quite some discussion about the new ‘Contexts’-feature that is going to be added to Elixir’s web framework Phoenix in version 1.3.
Some people are confused by them, some people believe ‘they are terrible’, some only believe that there needs to be a little extra information of how to use them in practice.
So, here are my two cents on how to approach contexts.
…
So reading your blog post @Qqwy, Contexts are just dedicated modules for functionality that can easily be classified as a group (and perhaps optionally) extracted from one big module?
(I haven’t got to learning Phoenix yet so please excuse my ignorance.)
A context is just a module, with some functions. Internally, a context module might call other modules with other functions. But the consumer(s) of the context do not care about that.
The fact that they are in a folder of their own maybe containing other modules making up the guts of the context is an implementation detail the consumer does not have to care about either.
Thanks for feedback @AlexMcConnell. In the future, please try to be less negative and more constructive with your feedback
I would also love to see you edit the title to something more constructive, like “Contexts may be a barrier to entry for newcomers” or something less inviting of inflammatory discussion.
I reject your premise that trying to help newcomers design their app with well defined modules and functions will spell an end to the success of Phoenix.
Since generators are learning tools, it’s exactly our goal to encourage folks how to build applications. Design patterns have no bearing on this and someone’s knowledge of them has nothing to do with their abilities or their potential success with Elixir and Phoenix. I don’t see this part of the argument. Just as our Channel generator doesn’t force folks to first learn OTP to use channels, context generators don’t force people to understand patterns or have a degree in system architecture. When a newcomer sees a generated handle_in(event, params, socket), do: {:noreply, socket}, we aren’t forcing them to know about stateful servers and GenServer reply values, but as newcomers sees this code and experiment with it, they are internalizing concepts that underly the runtime. In that same light, our goals with the context generators aren’t to force folks to be system architects, it’s to guide them along a path where they will internalize ideas about Phoenix as the web interface to “their app” and think about isolation. So when they see:
defmodule Blog do
def list_posts do
Repo.all(Post)
end
end
defmodule MyApp.PostController do
def index(conn, _) do
render(conn, "index.html", posts: Blog.list_posts()
end
end
They’ll start to understand, “oh, this is where I write my code, in modules and functions, not inside the Phoenix web bits”. We aren’t asking them to take a giant leap, rather baby steps along their way to isolated systems. We don’t expect them to get there immediately, but rather nudge them along the path to greater understanding.
Again, as this feature is a learning tool, we indeed are trying to educate newcomers on the virtues of these ideas, but we aren’t forcing anyone to understand or use anything in particular.
The framework is a couple years old now. Let’s agree to set a reminder in our calendars for two years from now and we can evaluate how things played out [quote=“AlexMcConnell, post:1, topic:5929”]
I’ve seen a lot of people saying, “Phoenix is not your application.” Well, stop it! Who are you to tell someone what their application is or isn’t. If they don’t understand the concept, repeating a catch phrase over and over isn’t going to fix the problem, it’s just going to encourage them to move on to something else with a community where people are being helpful rather than condescending.
[/quote]
As a community I think we do a fantastic job onboarding newcomers and avoiding being condescending. I do agree we can do a better job here with that phrase, but in my experience the folks using these phrases aren’t just chanting them, they are helping folks understand the concept. After all, the “Phoenix is not your application” talk by Lance (Phoenix core-team member) was all about the reasons why this is important and how it can help you.
This is what your OTP application is for, so introducing "app would have the opposite effect of what you’re hoping for I think. Also keep in mind that if a user’s app is trivial and named something like “MyBlog”, they could use their MyBlog base module as the “default” context. The generators are aware of existing files, so the context code would be injected in place. Something like that in the guides could maybe be a happy medium?
To be fair, constructive criticism is welcome and I think we’ve had a good bit of decent discussion in other threads, but most of the context feedback so far has been far from constructive. Instead of basing arguments in the abstract about somehow pushing folks away if they aren’t experts, it would be far better to talk around code and actual points of confusion. For example:
Instead of:
Contexts are terrible because newcomers will struggle. IT"S LITERALLY THE DEATH OF PHOENIX
We’d like to see this:
I’m struggling with Phoenix 1.3. I can’t decide where to place comments and votes for my Articles system. Should it live in my current Blog context, or be separate?
I just answered a comment like this on slack, and after asking them about their app, I recommended they create a ContentTracker context for tracing comments, votes, and page view statistics about entities in their system. We also discussed that they could add comments/votes to their Blog and there’s nothing wrong with that, but they were quite pleased with the ContentTracker ideas and it made thinking about boundaries really click for them. They wen’t from frustrated to epiphany and appreciation after just a little bit of help, which is our whole goal with the getting started process in general. It’s easy to argue in the abstract that something is good or it’s bad, but it takes more effort to actually present scenarios and come to a solution together. I’d love to have more of the latter
I totally agree I should have more experience before I can say anything that has more meaning than just a feeling but as you may have noticed I’m already an Elixir + Phoenix fan and I would really like to have the time to test them.
I am happy to see that you as the creator of Phoenix have accessibility in mind and I guess when I will finally have a chance to write my first API with it I can give a more constructive input.
What I wrote was just the feeling I get from this whole thread.
I still remember when I first tried to create my API gateway using Rails and how frustrated I got on the inability of the framework to give me what I wanted, so I ended up using Sinatra (which was a better fit and what I should have used from the start)
But I can still remember how 10 min after I started working with Rails I basically had a working web app, this is the kind of accessibility I would like to see in Phoenix - mainly because that is the framework I see the most potential in, this is regardless of context (which I think I’m going to love from what I read about it) I already have a web app in mind.
When I first discovered Phoenix, I fell in love with it because I understood it easily and got productive with it quickly because of the official guides and the Programming Phoenix book. When I grokked it, I was able to build three web apps in just a few weeks.
When Phoenix 1.3 and Contexts were introduced, I got more excited because I really think this is a good idea. So I began to try to learn and understand these new concepts. However, the official guides and the Programming Phoenix book haven’t been updated yet for Phoenix 1.3.
I have been stuck since. I haven’t even worked on improving my apps again. The introduction of a new concept without proper guides really has been a huge barrier for me to continue learning and using Phoenix.
I really really hope that the official guides and the Programming Phoenix book will be updated very soon. I have been stuck for a while now.
We’re working on the guides now, and the book work will follow. Do you have scenarios you can share where you are stuck? You said you “fell in love and got productive quickly” – even if you are having trouble without guides/books on 1.3, you can continue to enjoy your progress on code produced by the <= 1.2 generators, no?
I feel like it’s not only the scenarios in detail, which make people feel stuck when starting with 1.3. From my own experience it was rather the fact, that Contexts ask you to bundle up things before there are things to bundle and at a time, where you might not even know enough about which things are related and which aren’t. It’s asking for a decision, which you can do best after getting your hands dirty, but before generating the code you could get your hands dirty with.
And a related issue is schema association: If one finally setteled on some initial contexts (potentially still doubting they are correct) the next worrysome thing comes around the corner. Directly associate schemas across context or not to do it.
My takeaway would be the need to tell new phoenix users: “Don’t worry to much about context initially – think about them, but do not worry. (Even a ‘Core’ context is fine to start with.) Context most certainly will evolve/change; refactoring is simple in a functional language; so get your hands dirty and if better contexts emerge, refactor. No need to get it right from second 1.”
I know you’re working on the guides and the book. I am patiently waiting. Thank you so much for all your hard work. However, it would be really helpful if you published more articles or videos, even short ones, to help us achieve the correct mentality on all of these. Help us think how you think.
I learned Phoenix by using your book and generators. It was really easy to follow. Code in the book + code produced by generators = best practice. Or so I thought. What I now understand from your talk and your comments is that generators are just learning tools. After learning, we should stop using them. I’m the type of programmer who struggles to start a project on a blank slate. So this is a stumbling block for me.
Since my projects are still in the early stages, I prefer to continue working on them after I understand the correct way of doing things. The main thing for me right now is how to organize and name my modules and functions.
In my experience, when expressing a minority position in a community, it’s necessary to express that opinion very strongly in order to get others who share that position to speak up and see it actually addressed. People don’t like to disagree with the group, particularly when it’s against the biggest names in that group. My OP may not have been as constructive as it could have been, but it has led to a very constructive conversation, and that’s what leads us to the best result.
