Bike 2 Row.ID thoughts

Bike Outliner
1

Heads up and feedback!

Each row has a unique ID at runtime.

In original Bike 1.0 these IDs were also always persistent. So in your .bike file you’ll always see a unique ID associated with a row. Bike will also patch up IDs when the .bike file is read. So if you edit a .bike file to remove row IDs, or create duplicate IDs, Bike fixes things up on file read. At runtime (and on next save) every row has a unique ID.

This is still the behavior in Bike 2.0 for .bike files.

In Bike 2.0 .md files have a different behavior. The issue is most IDs are not important enough to keep and clutter your .md file. So instead what Bike does is discard row IDs when saving markdown, except when:

  1. The ID name doesn’t follow the generated ID pattern. In this case it’s assumed the ID was set for a reason and so it isn’t discarded. That’s why if you use the Calendar feature in Bike you’ll see that those IDs are written out into the markdown.
  2. IDs are also persisted into Markdown when there is a Row link (Bike > Format > Add Link to Row) to the row.

That approach mostly works, but has problems:

  1. The behavior is inconsistent between .bike and .md.
  2. It’s a bit mysterious how if you use a particular format the ID won’t be persisted
  3. If you create a link with “Bike > Format > Copy Link to Row” that link will break when the document is saved and reloaded.

I think the solution that I’ll go with is to change the .bike format behavior to match the .md format behavior. All formats will only write out the “important” ids, no longer an id for every row.

Second I think I will change the extension API to more closely reflect Bike’s internals. Internally each Bike row has two ID a numeric runtime id, and a string based persistent ID:

Row
  id: number // runtime only
  persistentID: string? // saved to file, will be optional string in next release
  ...

Currently when you say row.id via the extension API it’s actually the persistentID that is being returned. I think I’ll change this so that it instead return the runtime id. And I’ll add a new persistentID property for when you need access to a persistent ID. I’ll also add a new function row.ensurePersistentID(preference: string?) -> string that allows you to ensure that a row has a persistent ID.

Not sure if that’s too much text and detail to have a good opinion on, but if you have thoughts, let me know!

2 Likes
2

So in this scheme:

  • any (unique) { #identifier } in imported MD source will be mapped to Row.persistentID ?
  • and might .persistentID be writable from the API ?

(or might we perhaps need to make a new now, copying its data across, and adjusting any existing links elsewhere in the document which target the affected row ?)

(I’m thinking of a .bike doc analogy of annotating a Markdown line with a mnemonic
{ #identifier } )

3

Yes! Or I even think if it’s not unique then I will generate a unique persistent id for this case.

I’m not sure, but I’m leading toward making persistentId and optional property that you can set anytime you want on a row. If you try to set it to an id that already exists then it will throw an exception. Otherwise it’s just a property you can set.

That means if you change the persistent id of a row that’s linked to, then that link will break. But I don’t think that’s the end of the world… API can also delete the row, which will also break the link. So broken links are to be expected sometimes.

1 Like
4

:+1:

( and a user who does create a mnemonic identifier, for some reason,
will tend to make it before targeting the labelled row with links,
rather than after )

Or will quickly learn if they experiment with reversing that sequence :slight_smile: