Seeking your thoughts on Routex 1.2 pre-releases - localize Phoenix with minimal config

[BartOtten]

This thread once discussed Routex in it’s early form. It has been repurposed to gather feedback and discusses pre-releases.

Currently: pre 1.2.0
Target: localization with auto-detection of already used libs (Cldr, Gettext, Fluent), simplified setup, support for runtime dispatching and auto-plugs&hooks.

Official releases are announced at another thread: Routex - build powerful Phoenix routes: localize, customize, and innovate

Github: GitHub - BartOtten/routex: Build powerful Phoenix routes: localize, customize, and innovate
Main branch documentation: Overview — Routex v1.2.0-rc.1

[D4no0]

I don’t quite understand what this does and the example doesn’t help very much. Is this some kind of middleware between the router and the controllers or I am missing something?

[BartOtten]

Thanks for your reply.

For a more ‘real world use case’ have a look at Phoenix Localized Routes - Localized/multilingual routes in Phoenix. That libs is ‘one blob’ which does most things the extensions listed above do. While refactoring it, it’s features became almost extensions so Routex was born as Proof of Concept.

The new approach would

• allow developers to only include the extensions (and thus code) for features they need. Less code == less risk.
• or write their own router feature (such as Cloak) with a few lines for code. No need for a heavy fork, dealing with macro’s and other plumbing.

Routex, or better: the extensions, are mainly about transforming routes (/foo → /foo, /en/foo, /nl/foo) and adding helper functions for in components and controllers (get_other_language_page_urls(@url).

Routes itself provides a very small lifecycle hook for LiveView which can (and is) used by extensions that need to combine compile time information with runtime information. But that’s a ‘behind the scene’ thing.

[D4no0]

From what I understand this is done at compile-time and changes the macros/functions generated by router?

[BartOtten]

All ‘original’ code generated by Phoenix is preserved by Routex, but you do get the gist of it . That it all is done at compile-time is 100% accurate!

[D4no0]

I like the idea, my only concern is that it fights with router ideology. You define routes and expect them to be immutable, however routex can modify them, making the routes not the source of truth.

[BartOtten]

Although I see your point, Phoenix Router itself is no different in that it is not the most complete ‘source of truth’

• it generates Plug.Router routes behind the scene (although with the same path)
• ‘scopes’ segment routes in two or more parts. So ‘get /products’ might exists in code but not as URL.
• a ‘live’ route creates a ‘get’ route (piled with hidden parameters)
• a ‘resource’ route expands to a handful routes with different methods, paths and params
• a /websocket is magically added
• nitpicking: interpolation like :id and :token break ‘truth’ as those are replaced with arbitrary values

‘mix phx.routes’ comes closer and is the same for Phoenix Router and Routex, as Routex will generate Phoenix.Router.Route structs which Phoenix will compile to actual code[1]. So from Phoenix perspective the routes are just the same quality as the routes in router.ex

Routex generates more static routes such as /europe/nl/producten/:id instead of /:continent/:country/products/:id. So as far as immutability goes it’s actually clearer. You can exactly see which routes exist in the routes list.

——

1. this is an improvement over how Localized Routes works nowadays.
2. Thans for diving deeper and asking. Such questions should be answered by README/documentation; so they are very valuable.

[D4no0]

@BartOtten

this is an improvement over how Localized Routes works nowadays.

I’ve had to localize a project myself and it is true, there is a lot of manual handling you have to do both at routes and in liveviews, however since I didn’t have that many liveviews, doing it without a tool was fast enough.

In general it seems like a great idea, I would even think that addition of this feature in phoenix itself will be a big plus, so I am excited to see the result!

[BartOtten]

Rewritten opening post as documentation for Routex was written.

[BartOtten]

The renewed Opening Post should make clear how Routex fits in. Please let me know when it’s still not clear to you; writing clear documentation is not (yet) my stronghold.

You feedback has already inspired me to extend the documentation of the POC, leading to valuable insights about terminology (configuration module → Routex Backend, extend_using → preprocess_using etc)

[BartOtten]

Update

• Main modules and their documentation are good enough for first release.
• Helper functions to aid writing extensions and their documentation are good enough for first release.
• Initial set of extensions is POC quality and documentation has to be written.
• (minor) Messages printed by extensions have to be deferred to after processing.
• Needs more tests / moving extension tests to the extension folders

If someone is willing to help I am happy to provide access to the private repository

[kip]

@BartOtten well since Phoenix 1.7 is now out I have to get off my backside and finish up ex_cldr_routes to include localised VerifiedRoutes.

So I’m in for some collaboration as you proposed - and see if we can take your new library and integrate it.

[BartOtten]

A long time has passed but it was worth it! To celebrate a nice set of improvements, I released Routex 0.3.0-alpha.2.

As Routex was very much alpha, I took the liberty to break a few things for the better. If you used Routex already, check the Changelog where the breaking changes are listed.

Call for help!

I would love to collaborate on this lib! See some comments, PR’s or extensions from community members. The quality of this lib will benefit from multiple eyes. Feel free to contact me by personal message or other means.

Highlights

new! the process dictionary can be used to determine route branch
Routex solely used pattern matching on URL’s to determine which route branch (former scope) to use. Now the process dict key :rtx_branch -when set- overrides the URL matching.

new! extension Route interpolation
A route can be defined with route attribute interpolation. Any route attribute can be used!

live "/#{region}/products/#{language}/:id", ProductLive.Index, :index

new! module Routex.Matchable.
Uniform, better, faster, easier to use and it Just Works™. The functions in this module allow developers unexperienced with Macro’s and/or AST to create simple helper functions, while more experienced AST developers will be happy with the abstractions it provides as.

Matchables are an essential part of Routex. They are used to match run time routes with compile time routes.

This module provides functions to create Matchables, convert them to match pattern AST as well as function heads AST and to check if the routing values of two Matchable records match.

new! Module Routex.Branching
Provides a set of functions to build branched variants of macro’s. It’s interface is still a bit rough but it’s usable enough to build a new version of extension Verified Routes with it.

The renewed Verified Routes extension.
Using Routex.Branching it now also creates branching variants of url/{1,2,3} and path/{2,3} with, of course, configurable names. When the names of Phoenix are used an improved warning is displayed during route compilation.

improved: added the attribute ‘match?’ to the results returned by ‘alternatives/1’
The value is determined by a pattern match, so performance wise we’re good. It does make code clean.

<.link
        :for={alternative <- Routes.alternatives(@url)}
        rel="alternate"
        hreflang={alternative.attrs.language}
        patch={alternative.slug}
      >
        <.button class={ (alternative.match? && "bg-[#FD4F00]") || "" }>
          <%= alternative.attrs.name %>
        </.button>
      </.link>

---

Example app
Updated to use the latest version.
Example App
Github Example App

[BartOtten]

For those using Cldr.Routes and wanting to try Routex, a Cldr extension is on it’s way!

The convenience of Cldr.Routes combined with the power of Routex

[BartOtten]

It’s a wrap! Routex now has an adaptor for ex_cldr . In combination with other extensions it supports all features of Cldr.Routes such as translated path segment, interpolating locale data and verified routes…and then some[^1]!

BartOtten/routex/blob/main/lib/routex/extension/cldr.ex

@kip as you known infinity more than I do about Cldr, could you review the usage of Cldr?

[^1] “And then some” is an informal idiom that means and even more. It is used to emphasize that there is a large number or quantity of something.

[BartOtten]

A lib without a logo is as a vulnerability without a cool name. So I took the opportunity to dust of Illustrator and come up with a logo.

Every day a step closer to the first stable release

[BartOtten]

Not sure if I am

1. procrastinating
2. unhappy with the “looks like an Olympic Games logo” comments or
3. simply like to be back at designing after a few years.

Either way no code was written tonight.

Let me know if you have a strong opinion or favor in this matter

[D4no0]

I like B more.

For some reason I can’t stop thiking that this would be the perfect logo for Igniter .

[BartOtten]

—nvm—

[D4no0]

I think it already has a logo? igniter/README.md at v0.4.6 · ash-project/igniter · GitHub