How to identify specific queries in plugin reducers?

[MickeyKay]

I'm hoping to better understand how to identify specific queries within my custom plugin's reducer. Here's an artificial example to help better explain my question. . .

Let's say I have three components (A, B, and C), each decorated with a basic @connectWpPost. When component A's WP API fetch completes, I want to fire off a secondary action, but I don't want to do so for components B or C. In my custom plugin, I want to do something like:

reducers: {
  [ActionTypes.RequestComplete]: function (state, action) {
    if(currentFetchComponent === A) {
      doSomethingSpecial()
    }
  }
}

My question is, what's the best method to do the if(currentFetchComponent === A) above? I'm imagining I could use acion.id to do a lookup in the normalized entities array, however I'm wondering if there's not a more direct method. Thanks!

[sdgluck]

This isn't possible at the moment, unless with some trickery that I'm not aware of. If desirable we could add the component's displayName for which a request is being made to the request object? Open to other suggestions too.

[MickeyKay]

@sdgluck that could work, but I think a more robust solution might be to add a new param to Kasia queries for something like queryIdentifier. So you could do something like:
@connectWpPost('post', props => props.id, 'my-custom-query')

The my-custom-query could then be passed through to the reducer and would allow for much simpler identification of queries. Part of the issue with using the component name is that the same component could be used in multiple contexts, each with different reducer requirements, right?

If the above sounds compelling, I also wonder if it wouldn't make more sense to set yourself up for some future state with even more config by changing the signature to something like the following instead:

const options = {
  queryIdentifier: 'my-custom-query,
};

@connectWpPost('nw_review', props => props.id, options)

What do you think?

[MickeyKay]

Also, in case it's helpful, our actual use case has to do with setting the "primary" resource in our store. Amidst making a several Kasia queries for posts (e.g. 1. the main post and 2. related posts), we need a way to differentiate and flag the main post in the store.