I’m not sure how this should look in the dependency declarations. I guess it wouldn’t be possible to check the list of libraries depended on by other libraries from a function in the mix.exs file during declaration, right?
Yes, but that would require our library to non-optionally depend on one of them if we want to ensure at least one JSON library is available (or have the library’s users depend on one explicitly in their projects).
That’s it. In this specific case, we’d like to use Jason. If the project our library is installed in already depends on Poison, we want to use that instead, so we don’t add a dependency to a second JSON encoder.
My initial idea was to do that, but somehow fall back to Jason if none are available for seamless upgrades.
There doesn’t seem to be a way to get that to work, so we’ll probably ask users to explicitly depend on either one.
Ah, yes. I tend to forget the Let’s Split a 40% for some reason. I’ll put the Nyquist on my list to check out. Thanks! 🎩👌
Just restored my tmux session to the last time I accidentally pressed ⌃A+⌃S. We’re living in the future.
It’d be great if you could write it down, and I’d love to read your blog. A gist could work (and you can turn that into a blog later), but https://write.as looks promising as a blogging platform too. :)
That would be ideal, but I haven’t found a way to do that just yet. If all else fails, we’ll either have users explicitly depend on one, or switch to depending on Jason.
I’d prefer not to add another dependency if we don’t have to. Since their APIs are the same, we can switch between them in the library by checking which one’s available.
I’m leaning towards making both of them optional anyway, having users explicitly depend on a JSON encoder and figuring out which one’s available in the library itself. That won’t affect most users, as most projects have at least one of them available. 🤔
What’s the nicest way for an Elixir library to depend on either Jason or Poison? Ideally, it’d be like an optional dependency which uses whatever’s available. The libary needs a JSON encoder to function, though, so I can’t make them both optional.
I’d love to know what you think. How do contexts work with your current project? Do you feel like they help separate concerns, or do they tend to get in the way?
Ik? Soms zuurdesembrood, vaker pizza. Zij alweer taart. 🙄
Nice. Is that a Let’s Split? Would love to know how you like it after you’ve used it for a while.
brb, #heelhollandbakt.
That sounds like fun. I’ve been meaning to swing by your office for a while. Will DM. :)
“Managers” is quite descriptive, actually. Aside from the name, does it work similar to contexts in that it abstracts repository access away completely? What are the biggest differences?
I’d love to learn more about your approach! :)
☝️ Some (very rough) thoughts about contexts, sparked by our exchange. I’m planning to discuss context grouping, still. Would love to know what you think.
Trying something new. Here’s a braindump to explain contexts in Phoenix, which might eventually become an article. I’d love to know what you think.
https://gist.github.com/
Yes, like the generator (mv lib/weekmenu/schemas/* lib/weekmenu/). But please structure it a way you think makes sense. It’s all just functions, so it’s flexible like that. :)
Thanks, all! “Symbol (to) proc” it is. I must say I like Pretzel-colon too, but I’m a Twiddle-wakka kind of person. ;)
Because I needed it to post a multi-update reply, Dolphin now properly supports reply threads.
https://github.com/
Adding that namespace won’t break anything (nothing’s magically hooked up by name), so there’s no reason to advise against it. You’re free to do so, so please keep it if it adds clarity.
However, since you’ll never address the schema modules directly, I’d probably leave them un-namespaced and use the singular schemas and plural contexts convention.
Contexts provide the API to interact with your schemas to keep knowledge about your repository out of the rest of your app.
While they can group functions for multiple schemas together (like in the Accounts example), you’re encouraged to start with one context per schema if it’s not immediately clear what the groups could be.
For now, I’d call the context for the Recipe schema “Recipes”. Eventually, that context might manage both recipe and ingredient data, and you could have an Accounts context for handling users and their credentials, for example.
Architects
