expose GET action in stripes-connect

I marked it as "In Review" to indicate the pull request was up but not merged as I was waiting to get some feedback. Specifically from Niels. We talked about it in our meeting this morning though so I've merged it. Sorry, makes sense that you search for "In Review" to find things to review on folio-testing, I'll avoid using that status for anything else in future.

Is this something a developer would review? I wouldn't know how to test this.

This is done and the PR is up with an explanation of the syntax.

NB: the actions are still under props.mutator as has uncovered some issues with the merge props so I've made putting these under 'actions' rather than 'mutator' part of

I was thinking along the same lines and proposed something similar to in our conversation. I used the name GET "accessor" instead – mutator sounds weird for reading.

Well, we can do it, it's just incredibly awkward and inefficient at the moment, it's ludicrous and a distraction so I put it at the bottom.

Proposal: What Niels said months before, succinctly: a GET mutator ¹. This would be a function, passed in via props, that fetches a record and appends it to the resource's slice of the store (and consequently triggering a re-render). It would return a promise so that you can chain other mutations off of it (such as posting the loan).

This is inherently a different type of resource as the local state contains information beyond what is available from the back end (eg. which records are selected). So you would declare it as such in the manifest---either we create a distinct resource type or add a flag in the manifest, incremental or similar. This would exclude it from the usual fetch action/reducer and leave it managed by the explicitly triggered action for accumulating values.

Beyond the GET mutator it would probably also need a clear for when you want to reset the resource (eg. scanned a new users's library card).

What do you think? What's a good alternative?

¹ Of course, that doesn't really mutate anything, so maybe we should call mutators just... actions. Which, by semi-coincidence, they are in the redux sense as well, semantically leaving the door open for later exposing more of the underpinnings in an advanced-mode API that lets module authors create their own actions/epics/reducers for their slice of the store and interact with stripes-connect on the redux level.

Distracting ludicrous thing, no point in bothering attempting this, not sure why I wrote it up:

• create two local resources, scannedItems and checkedOutItems

• create an okapi resource items that uses scannedItems to create a query

• when scanned, add the item to scannedItems (causing items to refresh and refetch all items over again)

• if scannedItems is longer, POST the last item and append it to checkedOutItems on success