Fragments in Superglue is a simple way to help identify and mutate cross cutting concerns.

For example, a shared header, if marked as a fragment, will get updated across pages in the cache automatically, if that page header changes. This means that today, a fragment is duplicated across all pages, and updating is a process of iterating through the cache and making changes.

I haven’t used this feature extensively yet, and i’m unsure of its effectiveness. There may also be better ways of modeling this in redux. Maybe a fragment node somewhere in the tree and having a selector that takes the fragment and insert it in the page state. This way, we only have one source of truth. That would be nice, but that also conflicts with digging since we need the complete tree to mutate the page state.

Anyway, I think its worth marking it in the documentation as a experimental feature.

Today, Rails has Strada, a cordova-ish solution that brings the web to mobile by using web views and a JS bridge to native functionality. Superglue can offer a better alternative. Imagine being able to use standard Rails helpers (the flash, form helpers) and your boring Rails workflow to build React Native applications, all while having 100% Native UI controls and access to react-native libraries.

In other words, while Strada tries to bring the Web to native, Superglue tries to bring just Rails to native.

Thoughts

The movement towards "pages"

expo and other JS frameworks are making their way towards page based development. Since Superglue is about page state over the wire. Is there some compatibility here that is worth investigating?

Known quirks of React Native

ReactNative is not the web. Specifically

1. ReactNative fetch is NOT the web fetch, and there are known issues with redirects losing cookies
2. Cookies have more known issues. There is a react-native-cookies package that might help this issue.

Possible solutions:

1. Polyfill to the webview’s fetch. Its possible to create an instance of the Webview, and using injected javascript, create a polyfill fetch (fork something like https://github.com/developit/unfetch ) that proxys to the Webview.
2. Embrace the known Quirks. React native isn’t quite the web, so create helpers in superglue_rails that give Rails more superpowers. For example, we can embrace that React has an issue with redirect by never redirecting, instead we can render a payload for the app to navigate to somewhere else.

class PostsController < ApplicationController
  def create
    ... do stuff
    navigate_to_screen :home_screen
  end
end

‌

There might be new helpers to think about, for example: navigate_back. link helpersURL helpers.

Embracing React Native also means that some features of superglue would need to be disabled while on native. For example, UJS helpers. We may also need to reshape the redux state shape to accommodate the new navigation helpers.

‌

Next Steps

Of the solutions, I am leaning towards embracing React Native’s quirks. While I don’t have a thought out comparison, I think that because React Native isn’t quite web, its simpler to embrace to quirkiness then to add a layered solution. I believe that Rails itself can be a “Be productive anywhere” solution, even without the web.

The initial state generated by superglue_rails is already properly escaped json and can be marked as html_safe. But erblint may call that line out and recommend calling to_json before html_safe. We could add something like the below, or add some documentation on how to use with ERB lint.

<script type="text/javascript">
  window.SUPERGLUE_INITIAL_PAGE_STATE=<%= initial_state.html_safe %>;<%# erblint:disable ErbSafety %>
</script>

Fetching nodes requires the use a keypath in a url param on links and form elements, for example:

<a href="/?_breezy_filter=key.path.to.node.in.tree" data-bz-remote> Click to refresh this part of the UI </a>

I would rather not require the use of a parameter thats sort of private. How about something like this:

<a data-bz-remote="key.path.to.node.in.tree"> Click to refresh this part of the UI </a>

or this:

<a data-bz-remote data-bz-remote-node="key.path.to.node.in.tree"> Click to refresh this part of the UI </a>

There's a line in the controller generator that checks for a mobile option. This option is no longer used, and we're not currently targeting mobile. Lets remove the branch of logic.

Rail's form helpers are an incredible way to quickly build forms from backend objects. I'd like to have some parity on the superglue side so quickly build uncontrolled components on the React side without using RailsTag

Something like this:

json.form_props form_with_props(
  url: onboarding_income_index_path,
  model: current_user.profile,
  method: :post,
  scope: :profile, local: true) do |f|

  f.number_field :email, max_length: 5
  f.number_field :password
  f.number_field :password_confirmation
end

   {
     .....
     email: {
       input: { type: "email",  maxLength: 5}
      }
   }

then on the Javascript side:

<form {...formProps}>
  <label {...formProps.email.label} />
  <input {...formProps.email.input}/>

  <label {...formProps.password.label}>
  <input {...formProps.password.input}>

  <RailsForm.Field {...formProps.passwordConfirmation} />

  <input type="submit" />
</RailsForm>

We leave how to structure the form up to the user so they can do this if they want in only html:

<label {...formProps.email.label}>
  <input {...formProps.email.input}/>
</label>

All of superglue is written in ES6. For developers working with React, typescript has been a valuable tool to have. It would improve the developer experience if superglue was converted to Typescript.

Thoughts

Not all features of superglue can be converted to typescript.

1. digging is a feature that make it easy to create medium effort interactivity, but it works off of key paths (http://xyz.com/posts/?props_at=header.notifications)
2. Superglue also comes with UJS helpers, for example: using placeholders. Not sure what the best way to type this is.

Regardless, typing what we can is still a great step forward.

The release scripts on superglue are pretty simple, but I wish there was a more prompty way of releasing. I tend to forget which scripts to run first, and if i accidentally forget an argument, I end up with mistagged packages.

This is in the same vein as #43 . When moving to typescript, we also want to update the generators to output ts files.

Thoughts:

The generators are located in this folder. There are a total of 4 files there that needs to be converted (edit.js, index.js, new.js, show.js).

Superglue currently use CircleCI. I'd like to migrate and use github actions to test against rails main (to run weekly), 70, and 71. Today both form_props and props_template all use github actions. Here’s a build yaml used by props_template to get us started: https://github.com/thoughtbot/props_template/blob/main/.github/workflows/build.yml

I think making superglue’s gemspec a bit more conservative might make sense. Right now it uses.

  s.add_dependency "actionpack", ">= 7.0.0"
  s.add_development_dependency "activerecord", ">= 7.0"

Which says that it works with all future version of Rails. This isn’t 100% true as there’s a few monkey patches in `superglue_rails` that may not be compatible with future Rails versions.

We could

1. From the work to https://trello.com/c/SwB4ts3h/2-migrate-superglue-from-circleci-to-github test agains rails main weekly. Tho this is useful to do regardless of the change.
2. Be a bit more explicit and twiddle-wakka the versions.

I would like to see support for something like this:

json.foobar do
  json.value! 34
end

which is the same as:

json.foobar 34

The benefit with the block version is that it allows more lazy evaluation when using deferment or node filtering.

Currently, the generators assumes a typical Rails setup with sprockets as the main asset packaging mechanism. All JS boilerplate gets tossed inside app/assets/... and uses ES5.

Rails 5 users have the option of using webpack which uses the app/javascript directory instead of app/assets/.... I'd like to add a --webpack option to all generators to produce ES6 boilerplate that goes into app/javascript.

Acceptance

1. When running rails g breezy:install --webpack all existing javascript boilerplate should go in app/javascripts. See this as an example: https://github.com/jho406/kitchen/tree/master/app/javascript

• The view component should be translated to ES6 and tossed into app/javascript/components like so: https://github.com/jho406/kitchen/blob/master/app/javascript/components/view.jsx
• Same with the layout component: https://github.com/jho406/kitchen/blob/master/app/javascript/layouts/default.jsx
• Make sure there's a view folder: https://github.com/jho406/kitchen/tree/master/app/javascript/views

2. When running rails g breezy:view XYZ someaction --webpack all javascript boilerplate for the generator should go in app/javascripts. For example, https://github.com/jho406/kitchen/tree/master/app/javascript/views. Like the above, it should be in ES6.

3. Leave the boilerplate that produces app/views/layouts/application.html.erb the way it is. I don't think there's a need to change that.

BreezyTemplate is a sibling/fork of JBuilder, but due to the behavior of how set! works in Breezy (it doesn't merge, it overrides), it should be possible to implement multifetch caches pretty easily.

When using caching like this:

json.author(cache: ["some_cache_key"]) do
  json.first_name "tommy"
end

BreezyTemplates stores a javascript string like this in the Caching backend:

"Breezy.cache("some_cache_key", {first_name: "tommy"});"

Implementing multi-fetch should be just a concat on values fetched from redis. As opposed to JBuilder which returns Ruby from Redis and then merged with other values. See rails/jbuilder#289 for more information.

In Superglue's guide, there's a demo app (https://thoughtbot.github.io/superglue/#/demo), unfortunately, I found that the link is not working - https://github.com/thoughtbot/select-your-own-seat

Breezy was forked from Turbolinks 3, which was using coffeescript. I would like to convert the entire project to ES6.

A Superglue app’s directory structure looks like this:

app/
|-- controllers/
|-- views/
|   |-- dashboard/
|   |   |-- index.js # The React page component
|   |   |-- index.json.props # The json for the page component
|   |   |-- index.html.erb

‌

Almost always index.html.erb just contains a few lines:

‌

<%% initial_state = controller.render_to_string(active_template_virtual_path, formats: [:json], locals: local_assigns, layout: true) %>
<script type="text/javascript">
  window.SUPERGLUE_INITIAL_PAGE_STATE=<%%= initial_state.html_safe %>;
</script>
<div id="app"></div>

‌

Sometimes it may make sense to have that file to override, but is there a way to eliminate the need for these erb files so that the structure looks like:

‌

app/
|-- controllers/
|-- views/
|   |-- dashboard/
|   |   |-- index.js # The React page component
|   |   |-- index.json.props # The json for the page component

‌

That would be so much cleaner.

There's a CircleCI badge on the readme which we no longer use. It would be great if we can replace that with a github action badge.