What is the scope of trello frame in powerup callbackup

Trello
1

I am trying to setup some advanced behavior in a Trello powerup and I want to make sure I understand the expected behavior of the “t” frame for the PowerUp client library. (Client Library)

My question is, when you get a frame (t in all the examples), how long is that frame valid for?

More specifically, I am using the ‘bard-badges’ capability callback to monitor for changes on cards. Trello will automatically call the powerup when there are changes that may require the badges to update. Similarly I have some changes I want to handle in my powerup that I can trigger based upon the same change logic.

But in my case, the changes that need to happen are async and happen at some point later. So something like this:

  • card-badges called: tframe (scope: cardXXX, board YYY, …)
  • trigger async queued powerup work
  • create badge response
  • return from card-badges function
  • … time passes …
  • do some of the queued work for the card using the tframe variable

My question is, will the tframe variable and associated state/scope/whatever be valid at that last point after the card-badges callback has returned? ie. what is the valid scope of the tframe that is passed in. Can I hold onto it and use it at some point in the future inside the powerup code after the callback has returned or does the code that is calling the powerup callback functions do some cleanup that would render the tframe invalid?

I am seeing some errors like the set() method not being available, and the card not being set on the scope, etc and I don’t know if that is a problem on my side or if my expection about how long the tframe should be available and valid is just off. (I am expecting that I can use it even after the callback returns)

2

In general, I think the only expectation that has been set is that the state/scope is valid during the execution of the callback.

There may be a period of time where it is still valid afterwards, but that isn’t an expected use-case. But let me go ask around for a bit more clarification on what is happening under the hood to see if there isn’t better guidance.

In general, my read on what you want to do sounds like it is going to lead you down a path of frustration since it is outside of the normal scope of expected usage. It sounds like you’d be better off figuring out how to offload the work that needs to be done to a service outside of the Power-Up’s client library.

1 Like
3

Thanks. This is what I figured too.

I have some services in the powerup where I can use the REST APIs to perform the actions I need, but it appears there may be some type of caching layer in the powerup client API when calling methods like t.card('all'), etc. I was hoping to take advantage of that if possible to prevent having to make as many network calls. (note: I may be incorrect on the caching layer as I have never tracked completely through the internal powerup client code to verify)

4

You’re pretty spot on. I think (big think here :sweat_smile: ) that the client library taps into the web client’s cache of data and uses what it has. The web client stays up to date with data via websockets. There are a few rare occasions where a Power-Up can make a request for data that the web client doesn’t have that then does require the web client to make an API request to the server to grab it.

5

Any further feedback on where the handle to the client API is valid?

I am trying to find a way to reliably have some background code running on the board. The code needs to be able to read and write to the board and card data including plugins. Because plugin data can’t be written through the REST APIs, I have been using the client api reference to do this but I am hitting some corner cases where the API calls are failing with missing card and board ids at times.

I was guessing that the API reference somehow became invalid, but was hoping to prove if this was the case or not.