[note: I published the release notes on 2022-01-26 but neglected to push the version to RubyGems until 2022-02-02 which is why the dates don't match.]

• --nest has been renamed to --nested; please use --nested moving forward; if you use --nest you will be stopped and told to use --nested

• Please note that the --alt-controller-name feature has been removed. I decided that alt controller names were a bad idea and led to bad patterns, so I am removing them in favor of something else that I will release in the next version of this gem to achieve a similar goal.

• This upgrade has significant improvements to how child portals are handled. Specifically, child records now automatically pick the parent (ownership object) of the context they are created in.

Consider the classic User has_many :invoices

In this mini-example, notice that Hot Glue can build both God and non-God controllers which will have downnested portals (child tables) to the Invoices.

When you make a new Invoice, it gets created attached to the user in the context where you created it.

For Admin controllers it looks like this:

Notice that the invoices are created for the user in the right context.

(This mini example has a little trick where "invoice number" actually is an alphanumeric string of random letters & numbers -- see the source code for how it works.)

When viewing the same function in a different dashboard (for example, a dashboard where the user can see their own invoices but not other people's), we still have a "users" view and an "invoices" portal, but in this context, the user can only see their own record and can only see their own invoices:

Notice here that I have to log-in as the test user to get to the dashboard (Also, as you will see, I must manually type the URL of the dashboard for this example app)

Hot Glue now automatically knows if your authentication object (the thing your user will authenticate against) is the same as the scaffolding being built (for example, a user edit in their own record.) In these contexts, you won't be able to use create/new because the new object won't be authenticated. (If you were creating sign-up for, you'd make a God controller that had only a create/new action anyway, because that way the "general public" could use it without logging in.)

The Example app these screenshots are from is here
https://github.com/jfbcodes/SimpleInvoice4

Full Changelog: v0.4.6...v0.4.7

As a side-note I am very pleased with the progress and reception of the gem. The first few customers gave some great feedback and I have some very exciting features planned soon. This gem operates orthogonally to Rails Turbo and -- having developed it over the better part of the last year -- I do believe it complements Rails Turbo very nicely.

In particular, I do believe many enterprises will begin to come back to Rails now that the JS paradigms have been cleaned up with Rails 7. New CEOs/tech ventures should strongly consider Rails as a starting point for new apps, particularly as an alternative to JAMStack, Apollo, AWSAmplify or another "Backend-as-service," or something expensive like Java. Everything is going to have a cost, but a lot of these JAMStack choices are actually vendor lock-in in disguise.

Rails is cheap, fast, scalable, and easy to deploy. You get to own all of your code and ditch your hosting provider if you don't like their service. For all of these reasons and more, Rails still makes a great backend choice for your React Native, Swift or Kotlin mobile app.

Hot Glue is the perfect companion for building admin interfaces to complement a Rails-based GraphQL API. It's about making web dashboards quickly, easily, and cheaply. You don't want to spend a lot of time & money on CRUD, list, and simple dashboard views-- that's that part that in 2022 should be easy. You'd rather put your money, time, and effort into mobile and front-end interactions? You want your backend screens to mostly be cookie-cutter, highly functional, and "just work"? Me too! That's why I built Hot Glue.