Journal: Initial MVP #900
Journal: Initial MVP #900
Conversation
|
If this "standard Rails-only No TurboLinks" way of implementing furniture is faster/easier to build/maintain/debug, that's great. But what risks do we take or features do we lose by not using TurboLinks? The UI/UX for this feature still could use some improvements in a future iteration. Will that be possible with this current implementation? |
|
re: no Hotwire - Theoretically, the way Rails apps are supposed to work is you:
So it should be relatively straightforward to layer in hotwire to improve the UX. |
zspencer
force-pushed
the
journal/author-may-publish-journal-entries
branch
from
af8eb4f to
3880216
Compare
app/furniture/journal/breadcrumbs.rb
Outdated
| link 'Edit', [:edit, entry.space, entry.room, entry] | ||
| end | ||
| rescue NoMethodError => e | ||
| throw e unless e.message.start_with?("undefined method `crumb'") |
There was a problem hiding this comment.
What's this about? In which cases would we be throwing an undefined method crumb error, and why is that ok to swallow?
There was a problem hiding this comment.
OK this is HORRIBLE and I HATE IT but apparently Gretel's way of re-loading breadcrumbs uses an instance_eval; but if gets autoloaded by Rails and then it explodes.
There was a problem hiding this comment.
I fixed it by adding breadcrumbs to Zeitwerks ignore directive!
app/furniture/journal/room.rb
Outdated
| @@ -0,0 +1,7 @@ | |||
| class Journal::Room < Room | |||
| has_many :journal_entries, inverse_of: :room, class_name: 'Journal::Entry' | |||
There was a problem hiding this comment.
Is the only purposes of this new Room class to have the :journal_entries association?
I don't love it. It seems confusing to me, overloaded with our Room-Room, and causing us to have bits of code like room.becomes(Room)....
If the main purpose of this is to load the entries in Journal (without adding a has_many to our proper Room), I'd prefer we removed this class and instead implemented entries with an ActiveRecord lookup, like Entry.where(room_id: room).recent.
There was a problem hiding this comment.
Ya, this gets wiped in the fancier version of the PR.
|
Moved to draft because I wanna do it like we did the Marketplace. |
- [ ] Authorize + Policy Scope! - [ ] Styling! - [ ] Render the Entry HTML using Markdown
OK, this does *way* too much in one commit but YOLO. This: 1. Switches our Markdown Renderer from RedCarpet to Commonmarker because that's what Github uses :X 2. Updates `gretel` to support defining Breadcrumbs in Furniture! 3. Sprouts a `datetime_field` partial for rendering `datetime` HTML fields 4. Creates a Link between Person and Rooms through Spaces for permissioning ease. 5. Gives Journal Entries a Slug 6.
Co-authored-by: KellyAH <[email protected]>
Well, I couldn't figure out how to get the heading anchors injected using CommonMarker, and I really think that's important so :X
Apparently Gretel uses `instance_eval` to load it's breadcrumbs up; which is why `crumb` is available on `Object`. This is kinda a hacky-way to deal with that; but it may make sense for us to exclude the breadcrumb paths from autoloading somehow?
zspencer
force-pushed
the
journal/author-may-publish-journal-entries
branch
from
3880216 to
5c74d19
Compare
OK some stuff to think through: 1. Inheriting from FurniturePlacement could let us get rid of `Placeable`, which would be nice! 2. We could also then rename from `FurniturePlacements` to `Furniture`
See: Furniture: Journal
I wanted to explore what it would look like to do a pretty standard Rails-only No TurboLinks piece of Furniture; and this is what I got!
journal-demo.mp4