Episode 125 - Elixir 1.5 and Phoenix 1.3 Released

Elixir 1.5 https://elixir-lang.org/blog/2017/07/25/elixir-v1-5-0-released

Elixir v1.5 includes new features, enhancements, and bug fixes. While Elixir v1.4 focused on tools for concurrency and scalability, Elixir v1.5 brings many improvements to the developer experience and quality of life. As we will see, many of those are powered by the latest Erlang/OTP 20. This is also the last Elixir release that supports Erlang/OTP 18.

• UTF-8 atoms, function names and variables
• IEx helpers and breakpoints
  • IEx got many enhancements to the developer experience.
  • the autocompletion system is now capable of autocompleting variables and user imports
  • IEx also got new functions, such as exports/1, for listing all functions and macros in a module
  • Finally, IEx also features a breakpoint system for code debugging when running on Erlang/OTP 20
• Exception.blame
  • Exception.blame/3 is a new function in Elixir that is capable of attaching debug information to certain exceptions. Currently this is used to augment FunctionClauseErrors with a summary of all clauses and which parts of clause match and which ones didn’t
• Streamlined child specs
  • Elixir v1.5 streamlines how supervisors are defined and used in Elixir. Elixir now allows child specifications, which specify how a child process is supervised, to be defined in modules. (its just a little simpler)
• Calendar improvements
  • Elixir v1.3 introduced the Calendar module with the underlying Time, Date, NaiveDateTime and Datetime data types. We are glad to announce we consider the base Calendar API to be finished in Elixir v1.5. This release includes many enhancements, such as Date.range/2 and the ability to convert between different calendars.
• Compiler compilation time reduced by 10 - 15%, some applications have seen 30%

Phoenix 1.3 http://phoenixframework.org/blog/phoenix-1-3-0-released

Phoenix 1.3.0 is out! This release focuses on code generators with improved project structure, first class umbrella project support, and scaffolding that re-enforces Phoenix as a web-interface to your greater Elixir application.

Also making it into the 1.3 release is a V2 of our channel wire protocol that resolves race conditions under certain messaging patterns as well as an improved serialization format.

For those interested in a detailed overview of the changes and design decisions, check out my LonestarElixir keynote: https://www.youtube.com/watch?v=tMO28ar0lW8. Note that the directory structure in the talk is slightly outdated but all ideas still apply.

phx prefix instead of phoenix, YAY! LESS TYPING phoenix prefix still exists but will be removed in 1.4

1.3.0 is a backwards compatible release, so upgrading can be as easy as bumping your :phoenix dep in mix.exs to “~> 1.3”. For those wanting to adopt the new conventions, the upgrade guides will take you step-by-step. Before you upgrade, it’s worth watching the keynote or exploring the design decisions outlined below.

Design With Intent The new project and code generators take the lessons learned from the last two years and push folks towards better design decisions as they’re learning. New projects have a lib/my_app directory for business logic and a lib/my_app_web directory that holds all Phoenix related web modules, which are the web interface into your greater Elixir application. Along with new project structure, comes new phx.gen.html and phx.gen.json generators that adopt these goals of isolating your web interface from your domain.

WHAT THE CONTEXT!?

When you generate a HTML or JSON resource with phx.gen.html|json, Phoenix will generate code inside a Context. Contexts are dedicated modules that expose and group related functionality. For example, anytime you call Elixir’s standard library, be it Logger.info/1 or Stream.map/2, you are accessing different contexts. Internally, Elixir’s logger is made of multiple modules, such as Logger.Config and Logger.Backends, but we never interact with those modules directly. We call the Logger module the context, exactly because it exposes and groups all of the logging functionality.

action_fallback he new action_fallback feature allows you to specify a plug that is called if your controller action fails to return a valid Plug.Conn{} struct. The action fallback plug’s job is then to take the connection before the controller action, as well as the result and convert it to a valid plug response. This is particularly nice for JSON APIs as it removes duplication across controllers.