Bike 2 Extensions Preview

Looks good – thank you ! :+1:

( and I guess there’s an analogous pattern for lines selected in the ui, using the Selection interface? )

Yes, or at least close. While selection isn’t a RowSource selection has a rows property…

let outline = editor.outline
let selectionOutline = new Outline(editor.selection.rows)
let archived = selectionOutline.archive()     

Big test here… I “think” that should work but I haven’t actually tested. Ha! Not selection.rows are the highlighted rows, there are other more specific properties you can dig into.

1 Like

Got it.

( Constructing a new outline from a subset of an existing one seems very pleasing and elegant )

1 Like

Lately I’m making extensive use of Roam Research’s Cycle version functionality. Basically it allows every node to have multiple versions:
CleanShot 2025-04-10 at 20.23.21

There are many use cases for this; personally I use this to rapid-fire brainstorm different versions of a point in the outline (branching). There’s something liberating about hitting the equivalent of cmd+N and have a completely blank slate inside an existing document to work with, with history preserved. Also great for revision.

There are probably a gazillion workarounds to achieve something like this in current version of Bike (though not as neat), rely on macOS version control; or just have versions stacked on top of each other.

What’s neat about RR’s versioning is that once you select it, there’s only one ‘canon’ version. Other versions do not interact with the outline or graph, but they’re still there if you need them.

So…I wonder if Bike’s extensions could allow for something similar? :thinking: Maybe dump different versions of a row+descendants into an invisible part of the outline, and let them be recalled in some form?

Interesting question. I haven’t seen that cycle version feature before… I’m not sure that I quite get it, but I get parts of it anyway.

And I’m not sure.

Roam and Bike have pretty different data models. Bike is pretty much what you see is what you get. The data model is a tree of parent/child rows. Roam on the other hand is … I’m not sure. But there is indirection. I guess it’s maybe a tree (or multiple) of references to blocks.

An extension won’t be able to change that core difference.

And I’m not sure that I really want the ability to have some parts of your document unseeable. That’s not really possible (or for me wanted) in Bike.

With that said you could certainly write an extension that when you did maybe Command-Return would:

  1. Move current row somewhere “away”. Maybe into an “archive row”
  2. Inserted a new row in its place. Added a “prev-version” attribute to the new row that pointed to the old version.
  3. Then you could also create a command to cycle those versions… I think that would work.

I think a difference is that Bike’s core model is HTML/XML. A simple parent/child tree of rows. On the other hand I think Roam Research is a bit different, maybe a tree of references to blocks.

In my mind

And I suppose these rows with attributes could be styled differently with CSS, to somehow distinguish they have versions? Assuming a @prev-rowID attribute wouldn’t be visible out of the box

Yes, they could.

Another option that maybe I like better is instead of moving old version into an archive you could just leave it as a sibling to the current version and style it scaled way down (same styling that’s applied to non-matches when filtering)

Then all versions would be at hand, but only the current version would be fully readable.


And for data model maybe it could be simpler. A versioned row is just distinguished by having a @data-version=“” attribute. Rows are versions of each other when they all have that attribute AND they are siblings.

I think that model is simpler and maybe easier to understand.

Also the cycle version command would likely need to also search the outline for links to the current version and switch those out for links to the new cycled version?

Anyway, it’s an interesting idea, that I still don’t fully understand :slight_smile:

1 Like

Hmmm…what happens if you need to move rows around?

I’m not sure I like a solution that requires simultaneous movement of 2-3 rows instead of just one. Opens up room for mistakes for morons like me :sweat_smile:

Understand the use case for? I’m happy to show you how I use it in a real world scenario, maybe over Loom?

1 Like