Shared module constants

Thank you so much, good sir! I will shamelessly steal this, but mention your name for the glory

Yes it is.

Or you can use simple_enum (written by myself ^^) which does exactly the same thing with a few extra features.

Here is an example from the documentation:

iex> defmodule MyEnums do
...>   import SimpleEnum, only: [defenum: 2]
...>
...>   defenum :color, [:blue, :green, :red]
...>   defenum :day, monday: "MON", tuesday: "TUE", wednesday: "WED"
...> end

iex> require MyEnums

iex> MyEnums.color(:blue)
0
iex> MyEnums.color(0)
:blue
iex> MyEnums.day(:monday)
"MON"
iex> MyEnums.day("MON")
:monday

Is it still valid today?

I recommend that you take a look at the EctoEnum library for insights.

It’s worth mentioning to people coming to this thread that after getting used to Elixir it feels more natural to pass atoms around, so that’s not a big deal. The minor drawback is refactoring; you’ll have to find-all/ replace-all instead of just hitting the refactor/ rename button in your editor (the outcome tends to be virtually the same).

In most cases, having good documentation on the available options is sufficient.
Also, I think you shouldn’t worry too much about having autocomplete for that. Instead, you can write documentation and typespecs for your public APIs to achieve a similar goal.

I’m trying to achieve the same thing but with autocomplete functionality to know which atoms are available for use.
Would there be any performance drawbacks if I create a function for each key value pair?
I’m new to Elixir, sorry if this is a silly question

defmodule ErrorMessage do
  values = [
    account_not_found: "Error message for account not found" ,
    account_blocked: "Error message for account blocked" ,
    account_suspended: "Error message for account suspended",
    ...
  ]

  for {key, value} <- values do
    def unquote(:"#{key}")(), do: unquote(value)
  end
end

And then, when I need to use the error message

alias ErrorMessage, as: E
assert response === E.account_not_found

This way the editor offers me all available functions in the module as autocomplete

Just return a list of them then, no need to duplicate them.

Making a map of them can still be quite useful because it allows for O(log N) lookup instead of O(N) if you just need to verify it is valid or not (I generally do the values as just true in that case because convention, but doesn’t really matter).

Likewise, and baking them into a module like this is the way to do that, the values all get interned into the system and no GC will touch them and their linked usage anywhere will not trigger GC either, it’s very efficient.

Coming from a static language background it’s really hard to get around the “elixir-way”.

@OvermindDL1 What would be your approach if instead of integers you’d need a list of atoms?
Imagine if you needed to validate a list of valid countries; it seems a bit overkill (due to repetition) to just:

def countries, do: %{
united_states: :united_states,
canada: :canada,
paris: :paris,
england: :england
}

# maybe just... (???)
# def valid_countries, do: [:united_states, :canada, :paris, :england]

Instead of simply scattering atoms in the application, I like the idea to have a “single source of truth” to serve like self-documentation (mainly autocomplete). In that case, I’d typically use an enum or a class with static const properties in C#.

PS.: BTW I don’t like very much the idea of using loose JSON files in the project like @benperiton.

Seems I’ve been spending too much time using things that live reload code, the files DO recompile if I change the JSON, I was just waiting for it to happen live

I’m sure there are things I can tweak in the below, but it seems to work fine for what I need right now.

• Split over multiple JSON files
• Custom Ecto field for converting when entering/retrieving from DB
• Allow atoms to be used during dev/debug, but integers for storage/comms
• Re-compiles when any JSON file changes
• Dynamically create “nested modules” based on the JSON filename

So this is end result of all the suggestions (thanks again!)

defmodule API.Const do
  @moduledoc """
  A single point that we can use constants from. Rather than using something
  like a map to expose atoms => integers we create a set of functions that 
  let us encode/decode from either atom => integer or integer => atom. Doing this
  makes it a lot easier to debug things as we are basically just using atoms 
  everywhere in the code - we change to integers on the app boundary.

  We still break up the constants with regards to their respective areas, and 
  then we just include everything in here. We store the constatnts as JSON files
  so that we can export into frontend clients if needed,

  Discussion here: https://forum.elixirforum.com/t/shared-module-constants/2799/
  
  Eg:

  API.Const.System.encode(:ORG_STATUS_ACTIVE) => 100101
  API.Const.System.decode(100101) => :ORG_STATUS_ACTIVE
  """

  @root_dir       File.cwd!
  @const_dir      Path.join(~w(#{@root_dir} lib imsapi common constants))
  @const_files    Path.wildcard("#{@const_dir}/**/*.json")

  for filename <- @const_files do
    # Watch for changes and recompile
    @external_resource filename

    # This will be the new module: API.Const.<group>
    group = filename
            |> Path.basename(".json")
            |> String.capitalize

    file_consts = File.read!(filename)
                  |> Poison.decode!

    
    # Creates a module under the main API.Const module using the filename.
    # 
    # Eg a system.json file would end up as `API.Const.System`
    defmodule Module.concat([API, Const, group]) do
      for {key, value} <- file_consts do
        def encode(unquote(String.to_atom(key))),   do: unquote(value)
        def decode(unquote(value)), do: unquote(String.to_atom(key))
      end

      # Creates a new module that can be used with Ecto models to hsve s field
      # that is automatically encoded/decoded as data is retrieved/entered.
      # Name is the same as the outer module, with `Ecto` appended
      # 
      # Eg a system.json file would end up as `API.Const.System.EctoField`
      defmodule Module.concat([API, Const, group, EctoField]) do
        @behaviour Ecto.Type

        @group_mod Module.concat([API, Const, group])

        def type, do: :integer

        def cast(int) when is_integer(int), do: {:ok, apply(@group_mod, :decode, [int])}
        def cast(atom) when is_atom(atom), do: {:ok, atom}
        def cast(_), do: :error

        def load(int) when is_integer(int), do: {:ok, apply(@group_mod, :decode, [int])}
        def load(_), do: :error

        def dump(atom) when is_atom(atom), do: {:ok, apply(@group_mod, :encode, [atom])}
        def dump(_), do: :error
      end
    end
  end
end

Thanks guys, I’m really liking where this has gone! So, I’ve tried to implement both of those ideas, and I now have

defmodule API.Const do
  @root_dir       File.cwd!
  @const_dir      Path.join(~w(#{@root_dir} lib imsapi common constants))
  @const_files    Path.wildcard("#{@const_dir}/**/*.json")

  for filename <- @const_files do
    # Watch for changes and recompile
    @external_resource filename

    # This will be the new module: API.Const.<group>
    group = filename
            |> Path.basename(".json")
            |> String.capitalize

    file_consts = File.read!(filename)
                  |> Poison.decode!

    defmodule Module.concat([API, Const, group]) do
      for {key, value} <- file_consts do
        def encode(unquote(String.to_atom(key))),   do: unquote(value)
        def decode(unquote(value)), do: unquote(String.to_atom(key))
      end
    end
  end
end

That makes a much nicer way to access the different files, so thanks for that suggestion @sasajuric! I’m not sure if I’m doing something wrong, but it doesn’t seem to recompile if I modify one of the JSON files?

I’m running it using iex -S mix phoenix.server

You could also reach for multiple “nested” modules. Basically, for each input json file name, create the module alias using Module.concat, and then define the module dynamically. That way you could invoke say Const.System.decode/encode, assuming the input file is system.json.