From afab0cb86869db94655c92f58c46ba07ef1e25bf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Valim?= Date: Sat, 21 Oct 2023 12:56:59 +0200 Subject: [PATCH] Add new entry to context FAQ --- guides/contexts.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/guides/contexts.md b/guides/contexts.md index 1cd73bbd7b..55d3dc87ed 100644 --- a/guides/contexts.md +++ b/guides/contexts.md @@ -923,7 +923,7 @@ defmodule HelloWeb.CartHTML do use HelloWeb, :html alias Hello.ShoppingCart - + embed_templates "cart_html/*" def currency_to_str(%Decimal{} = val), do: "$#{Decimal.round(val, 2)}" @@ -1348,6 +1348,16 @@ Great work! ## FAQ +### How do I structure code inside contexts? + +You may wonder how to organize the code inside contexts. For example, should you define a module for changesets (such as ProductChangesets) and another module for queries (such as ProductQueries)? + +One important benefit of contexts is that this decision does not matter much. The context is your public API, the other modules are private. Contexts isolate these modules into small groups so the surface area of your application is the context and not _all of your code_. + +So while you and your team could establish patterns for organizing these private modules, it is also our opinion it is completely fine for them to be different. The major focus should be on how the contexts are defined and how they interact with each other (and with your web application). + +Think about it as a well-kept neighbourhood. Your contexts are houses, you want to keep them well-preserved, well-connected, etc. Inside the houses, they may all be a little bit different, and that's fine. + ### Returning Ecto structures from context APIs As we explored the context API, you might have wondered: