nikolis
Working with many to many relationship though user input(Form)
So I have being playing around with an app to better digest elixir and I have come across a tough choice.
In my user case scenario there a user can create he’s own user meal, this meal can have multiple food recipes and as it seem natural a food recipe can be part of many user meals. So how I am handling this is through a many to many association in the db layer.
UserMeal <-(RecipeUserMeal)-> Recipe
so in order to create the recipe_user_meals field of the UserMeal automatically when perssisting a UserMeal Struct I would need something like [%{recipe_id: 1} , %{recipe_id: 2}] etc ..
How I am handling that in the form creating the UserMeal I have a multiple_select so that the user can select multiple recipes if needed to associate with the particular UserMeal but the multiple_select is actually producing an array of ids like ["1", "2"] and how I am currently handling that is using a tranformation function. to convert the multiple_select content (["1", "2"]) to something the ecto can understand
([%{recipe_id: 1} , %{recipe_id: 2}]). but this converertion that needs to happen one way in whenever I am having a direction from live_view form to ecto and the other way when I am going from ecto content to live_view form kind makes my code fuzzy and difficult to understand.
So to those of you that have come across anything similar
Do you have any suggestion for me ?
Could it be that should I create my own multiple_select building on top of the Phoenix.HTML.Form one so that it feets my needs in particular ?
Am I missing something really obvious even in the db model layer that could make my life easier ?
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance











First Post!
evadne
Would suggest reviewing Ecto virtual fields, perhaps you can find an opportunity there for simplification. Consider using an Ecto schema just for form interoperation and roll it to/from the base model that can be used with the database with additional code