Are you still updating this?

[alecmce]

Hi, I heard that the main contributor to this is no longer part of protectwise. I have a modest API change that I'd like to propose. Is it worth pursuing?

[lojjic]

@alecmce You heard correctly, but I will continue contributing. What's your API change proposal?

[lojjic]

Is your use case for the callback something that wouldn't be served by the synccomplete event listener? I usually recommend that as a more robust solution because it is guaranteed to fire whenever the rendering is updated.

[alecmce]

The synccomplete event only gets called when _needsSync, though? The use-case of "I don't know whether you need to sync or not troika, but if you do, sync, and when you're done, trigger this callback ... if not, just trigger this callback!" is what I really want. A "promise", more or less. To do that I can't see any way around reading _needsSync directly. But the _ implies I shouldn't be doing that.

[lojjic]

OK thanks, I think I can envision your use case now. I've only ever needed to react to changes and not cared about the no-changes case, but I can see potential uses where you'd want to wait for the state to be complete before continuing with your logic.

I'd be fine with:

• adding a public needsSync property you can check
• making the sync() method return a Promise, which would be resolved when the text is next in "synced" state (right away if it doesn't need a sync.)
• ... both?
• ... something else?

[lojjic]

Actually rather than a needsSync boolean, we'd probably want a new status enum. Something like {needs_sync, syncing, synced} to handle the intermediate case.

[alecmce]

I've ended up porting the main Text.js api to TypeScript within my our project and refactoring the sync mechanism for our own purposes, so I'm not looking for a change in this project anymore. For what it's worth, I'm broadly doing:

sync(callback: ApplyTextRenderInfo = NULL_FN): void {
  if (this.isValid) {
    callback(this.info)
  } else {
    this.queue.push(callback)
    this.debounce(this.flush)
  }
}

flush = (): void => {
  const queue = [...this.queue]
  this.queue.length = 0

  getTextRenderInfo(this.state, info => {
    queue.forEach(fn => fn(this.info))
  })
}

though there's a problem with this approach that if you sync1/invalidate/sync2/response1/invalidate/sync3, the sync3 callback will be triggered with the response1, so I need to fix that race-condition. I'll check with my boss whether it's ok to share the actual code later. The debounce is because different modules of code may have a reference to a single Text instance and may manipulate different aspects of it, then perform different actions based on the text render info that is returned.

Anyway, thank you for the very effective implementation. The API doesn't quite fit our use-case, but in the end it's probably simpler that we rewrite the API while standing on the shoulders of your implementation, rather than seek to modify your API.