Skip to content

Conversation

StreliaPico
Copy link

Pull Request Description

This PR adds a parentId field to the ButtonContext object, which is passed in the context for JS functions when a button is clicked.

The field is a string containing the ID of the parent element in the DOM.

This is so you can write JS that the button executes, and it can know where in the DOM it is to be able to perform position-dependant logic.

Potential Issues

  • Determining the "parent element" is a bit tricky, as it depends on if the button is inline or not. I added a check for that but I may have missed other cases.
  • I don't use Typescript often if at all, nor am I familiar with Obsidian plugin development practices, so I may have made some missteps in the code somewhere.

Test results

All tests pass:

 2067 pass
 0 fail
 8500 expect() calls
Ran 2067 tests across 13 files. [3.94s]

Motivation

The obvious question here is "what is this even for?"

My use case is that I have an ever-growing to-do list that I add to and update daily.

Upon opening my to-do list, a dataview script reads through all my daily notes and compiles the to-do list items from each one into a table. It then adds meta-bind buttons (and a date spinner) to each row to allow me to edit data for each row which gets inserted as frontmatter.

The issue is that using dataviewjs to create buttons in this way is a bit hard. As there's custom logic for each different button (to point to different frontmatter keys), I ended up instantiating a new button with a unique ID for every row with data prefilled in. This has led to a ballooning in processing time.

To combat this, I thought it would be better if it was just one set of buttons duplicated per row, but it knew what row it was on to not need the instantiation. Hence this PR. (I had tried passing in the DOM element directly into the context instead, but JS wasn't having that due to structuredClone shenanigans. Thus, the parent's ID was the best I could come up with.)

I currently have a little over 700 entries in my list, and this change cuts down the loading time from 40 seconds to 10 (It also automatically reloads every time I make a change so it really adds up). It's still a bit on the high side. I realize I should probably be using a different (or custom) plugin for this at this point.

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.

1 participant