⚠️ Warning: you are accessing the variable "translate_error" inside a LiveView template.

[nelsonic]

When running the items-list branch I'm getting a few of these warnings:

==> petal_components
Compiling 25 files (.ex)
warning: you are accessing the variable "translate_error" inside a LiveView template.

Using variables in HEEx templates are discouraged as they disable change tracking. You are only allowed to access variables defined by Elixir control-flow structures, such as if/case/for, or those defined by the special attributes :let/:if/:for. If you are shadowing a variable defined outside of the template using a control-flow structure, you must choose a unique variable name within the template.

Instead of:

    def add(assigns) do
      result = assigns.a + assigns.b
      ~H"the result is: <%= result %>"
    end

You must do:

    def add(assigns) do
      assigns = assign(assigns, :result, assigns.a + assigns.b)
      ~H"the result is: <%= @result %>"
    end

  lib/petal_components/form.ex:412: PetalComponents.Form.form_field_error/1

We need to do whatever it takes to not have these kinds of warnings in our app. 🙏

[nelsonic]

@LuchoTurtle can you please confirm if you are still seeing this warning when running the MVP on your localhost #190 💭 🙏

[LuchoTurtle]

@nelsonic In the items_list branch, yes, this warning still pops up.

This branch's dependencies are outdated when compared to the main branch.

[nelsonic]

OK. Let's review this when I'm back at my desk. for now ...

[nelsonic]

Derp! 🤦‍♂️ Sorry that was an unintentional close. 🤦‍♂️
For now ... #195

[LuchoTurtle]

I'm trying to get this fixed but to tackle this, I had to make #165 up-to-date with the main branch, which involved fixing loads of merging conflicts.

Although the PR is still in progress, the reason I'm a bit "stuck" is that the original PR (#165) uses the person table, which no longer exists. So to get this PR up to speed with the current changes of the main branch, the database schema definitions need to be reworked to make it work.

Originally, the PR introduced two new tables: ListItem (bridge table between Item and List) and List (which has a name, person_id referencing the Person table and lists_name_person_id_index, which forced uniqueness in the table - see https://github.com/dwyl/mvp/pull/165/files#r991038501).

Now that the Person table was removed, person_id can't be a field in this table. This will affect operations like "fetching a user's lists". How should we manage the lists for each person now?

I've created #351 which will hopefully be merged into the items-list branch in #165. It fixes compile-time errors however, even though I could remove any instances of a person_id in the List schema definition and change the way we fetch a user's list, I thought it'd be better to get some feedback first.

My intention was to, at first, remove the person_id field completely from Lists and hopefully get this merged so we have #165 up-to-date and then focus on adding groups and lists for different people. But I prefer to leave it to the pros first.

[LuchoTurtle]

Closing this issue because the items-list branch is not tossing errors now when running mix phx.server, mix compile or mix c. 👌