Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Operation slot machine #2301

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

Operation slot machine #2301

wants to merge 5 commits into from

Conversation

zspencer
Copy link
Member

@zspencer zspencer commented Mar 14, 2024

@rosschapman ran into a weird bug when ActionTexting the MarkdownTextBlock where the action text couldn't save itself. Basically we were using nested attributes with a faux-relationship; which meant the actual MarktdownTextBlock was not getting saved.

@anaulin pointed out that this is an example of the single-table-inheritance being annoying, and that maybe we should finally deal with the cruft and blurry lines from our initial Furniture implementation.

So we started down the path of a refactor where we make a Slot responsible for where in a particular Section a Gizmo should live; and which Gizmo should live in that spot.

So we wrote a System Spec, and then we started implementing it and realized we had gone down the wrong pathyway, we want to create the Gizmo first and then add the Slot!

So we're going to reset and move forward with making a Card for each Gizmo!

  • Change the Sections#edit page so that our new Gizmo management interface is a collection of CardComponents that link to the particular Gizmo's #new page.

@zspencer zspencer force-pushed the operation-slot-machine branch from 5b2a42c to c8b7267 Compare March 28, 2024 00:02
We talked a bit at ensemble and Ana made the astute observation that
the complexity of how Gizmos work using hand-wrolled single table
inheritance is probably the biggest drag on development right now.

So we're starting to untangle that by building up a way to `Slot` in
`Gizmos` like the `Marketplace` or a `TextBlock` without the baggage of
`Furniture`'s single-table-inheritance.

Going forward, each `Gizmo` will need it's own `Model` and table for
storing data; as we will eventually ditch the `furnitures` table
completely.
We decided that instead of creating a `Slot`, we want to create Gizmos
directly, and we want to make those `Gizmo` by sending users to the
actual `/new` page for the particular `Gizmo`.

We're thinking we will make the UI cards of Gizmos, so that they can
include things like why you might want to add that Gizmo, or the help docs
or the ... whatever. We don't know. It'll be fine.
@zspencer zspencer force-pushed the operation-slot-machine branch from 2e0dcd4 to 8c6ef8d Compare April 18, 2024 00:14
@zspencer zspencer force-pushed the operation-slot-machine branch from ac283bc to 5f6a10e Compare April 18, 2024 19:36
@anaulin
Copy link
Member

anaulin commented May 30, 2024

If I'm understanding the notes in the PR description correctly, the underlying issue that @rosschapman was running into was the STI-iness of MarkdownBlock. This could be improved by migrating MarkdownBlock to be a Gizmo based on its own table, and not using the shared furnitures table.

There is an adjacent, but separate, issue around improving how we (re)order Gizmos. After Ross' introduction of the positioning gem, it feels like a good next step in this direction would be to remove the RankedModel gem altogether.

(Writing this down because Ross and I were just discussing next steps on this.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants