My reason to chose a keyword list over a map is the fact that the user inputs a keyword list when creating a Ecto.Enum field, so it seemed consistent returning the exact same thing the user inputted. Yet, as you pointed out, this didn't reflect the exact mappings that are done on on_dump and on_load (these are maps, and the last one would take precedence). I opened another PR that prevents the user from inputting keyword lists with duplicate keys.

Duplicate values make so that only the last of the duplicates is taken into account, due to the fact that the keyword list is cast into a map for the on_load and on_dump values. With this commit we can avoid this scenario in compile time.

Pointed out by @wojtekmach on #3676

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

Closes #241

The return value here is a 5 element tuple, rather than the 4 element tuple declared in the typespec:

The typespec:

https://github.com/elixir-ecto/db_connection/blob/4d7e789943f1c3a0b54b871f3807a04303e666dc/lib/db_connection/holder.ex#L50

The offenders:

https://github.com/elixir-ecto/db_connection/blob/4d7e789943f1c3a0b54b871f3807a04303e666dc/lib/db_connection/holder.ex#L57

https://github.com/elixir-ecto/db_connection/blob/4d7e789943f1c3a0b54b871f3807a04303e666dc/lib/db_connection/holder.ex#L77

Closes #241

The return value here is a 5 element tuple, rather than the 4 element tuple declared in the typespec:

https://github.com/elixir-ecto/db_connection/blob/master/lib/db_connection/holder.ex#L57

Adds a template for capturing bug reports from user's of Surface.

When attempting to use {... } syntax on a slot, you get an unexpected error message at the usage of the slot's component.

How to reproduce

<#slot {...Map.get(@something, :val)} />

Error

** (CaseClauseError) no case clause matching: {{:default, 0, %{}, %{state: ...omitted...}}}
        (scout 0.1.0) lib/myapp/live/show.sface:1: omitted
        (scout 0.1.0) lib/myapp/live/components/workflow.ex:25: omitted
        (phoenix_live_view 0.15.7) lib/phoenix_live_view/diff.ex:356: Phoenix.LiveView.Diff.traverse/6
        (phoenix_live_view 0.15.7) lib/phoenix_live_view/diff.ex:430: anonymous fn/4 in Phoenix.LiveView.Diff.traverse_dynamic/6
        (elixir 1.12.0) lib/enum.ex:2356: Enum."-reduce/3-lists^foldl/2-0-"/3
        (phoenix_live_view 0.15.7) lib/phoenix_live_view/diff.ex:356: Phoenix.LiveView.Diff.traverse/6

Expected behavior

A compile-time error should be raised that it is invalid to use {... }, :attrs and :props on a slot. Instead, the :args directive should be used.

When a stateful live component has multiple root elements and one of those elements is a HTML comment then this comment is turned into a span.

In my case:

<!-- my comment -->

Turns into:

<span data-phx-component="6"> my comment </span>

Just encountered this issue as well.

Safari 14.0.3 MacOS 11.2.3

Environment

• Elixir & Erlang/OTP versions (elixir --version):

Erlang/OTP 24 [erts-12.0.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.12.1 (compiled with Erlang/OTP 22)

• Operating system: macOS Big Sur 11.2.3

Current behavior

iex(1)> String.to_existing_atom("valid_utf8")
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: invalid UTF8 encoding

    :erlang.binary_to_existing_atom("valid_utf8", :utf8)

The error is a lie. It's valid UTF-8, it just doesn't exist as an atom.

Expected behavior

It would be great if it could tell us the atom doesn't exist. If that's not possible though, we should at least stop giving an incorrect reason.

Precisely, thanks @thiamsantos and @JEG2!

I think it is the same error reported at https://github.com/elixir-lang/elixir/issues/11014. It seems to be already fixed in OTP https://github.com/erlang/otp/commit/c1942e39d44d50bb4bdf8e22456f31ee23931fdb.

Environment

• Elixir & Erlang/OTP versions (elixir --version):

Erlang/OTP 24 [erts-12.0.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.12.1 (compiled with Erlang/OTP 22)

• Operating system: macOS Big Sur 11.2.3

Current behavior

iex(1)> String.to_existing_atom("valid_utf8")
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: invalid UTF8 encoding

    :erlang.binary_to_existing_atom("valid_utf8", :utf8)

The error is a lie. It's valid UTF-8, it just doesn't exist as an atom.

Expected behavior

It would be great if it could tell us the atom doesn't exist. If that's not possible though, we should at least stop giving an incorrect reason.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

Environment

• Elixir version (elixir -v): Erlang/OTP 23 [erts-11.2] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]
• Absinthe version (mix deps | grep absinthe): absinthe 1.6.4 / absinthe_plug 1.5.8
• Client Framework and version (Relay, Apollo, etc): graphiql

Expected behavior

Changing my types file from field(:id, :id) to field :id, :string do resolve(fn object, _, _ -> {:ok, GlobalId.encode(Spiff.Comment, object.id)} end) end

Sometimes does not register as a change

Actual behavior

id continued to behave as a plain db column until I ran mix clean and restarted. Then it works as expected. Restarting iex on its own is not enough to break the stale cache.