Add lorisFetch wrapper for centralized 401/login handling

[Montekkundan]

Summary

• Add a small fetch wrapper that centralizes 401/login modal behavior.
• Wire it so it’s available globally.

Why

• Prevents each module from re-implementing session-expiry handling.
• Keeps fetch behavior consistent across modules.

What changed

• Added jslib/lorisFetch.js
• Wired into htdocs/js/loris-scripts.js

Tests

did not run (no functional changes beyond wrapper wiring).

[HenriRabalais]

Hey @Montekkundan ! great work on this set of lorisFetch PRs.

I don't mean to throw a massive wrench in your work, but I've been working on an implementation to resolve some of issues you're tackling here and it's just been merged in #9999 .

It would be great if we can make use of this new HTTP Client system. I think your series of PRs would also be a great way to stress test it, find its limitations and expand where necessary.

I think a good rule of thumb could be:

• For JSON/Data requests: Let's use the Client class. It will save you from having to manually parse JSON or handle response.ok and error text in every component.
• For HTML fragments/Tabs: Stick with lorisFetch as you've implemented it. The Client is strictly for RESTful JSON data, and I think it’s cleaner to keep the 'HTML' logic separate rather than forcing it into a data client.
• We can even update the Client to use your lorisFetch internally so we keep your 401/login modal logic everywhere.

@driusan what do you think? If yes then @Montekkundan I would be happy to give you any information you need to get it functioning.

[Montekkundan]

Makes sense to me. I reviewed #9999 and I’m aligned with using Client for JSON/data requests and keeping lorisFetch for HTML/tab flows.

I’ll wait for @driusan confirmation before changing the PRs.

@HenriRabalais if you have a preferred migration pattern for existing modules (where to define client classes, how to surface errors in UI, and how to handle query params), please share and I’ll follow it in follow-up commits.

[driusan]

@HenriRabalais I agree with the idea and I leave it up to you to decide if it should be updated to use lorisFetch, since you're the one who reviewed the lorisFetch code and you know the Client architecture.

[HenriRabalais]

@Montekkundan Module-specific Client classes should be stored within the model in the /jsx directory. You can follow the directory structure for Acknolwedgements from #9999. For errors, you can catch them using a try block whenever you run a Client operation. I'm working on an Alert class for standardized error handling, but it's not complete yet. As for an example of the Client implementation with query params, I've left a code block example on your Document Repository PR! It might need some tweaking, but that would be the general principle.

[Montekkundan]

@HenriRabalais follow-up pushed per client guidance. Could you re-review when you have a moment? Thanks 😄!

[HenriRabalais]

Hey @Montekkundan, thanks for the PR updates!

I think I might not have been clear about how to set up the Client subclasses. These subclasses (e.g. CandidateParametersClient, etc.) should serve as convenience wrappers for the methods already defined in the parent Client class (get, create, update, etc.). You've done this well in the DocumentRepositoryClient!

To keep our architecture clean and our error handling consistent:

• No native fetch calls: All requests must use the base class methods to ensure our global error, response, query, and URL building systems aren't bypassed.
• JSON Only: Our Client is strictly for REST/JSON. If an endpoint is legacy (requiring Form-encoded data or returning raw Text), it should be handled by your new lorisFetch utility for now.
• Encapsulation: I'll likely be making fetchJSON private/protected so that all interactions are forced through the high-level API methods (get, create, update, etc.), so please avoid using Client.fetchJSON.

We don't want to treat the Client as just a place to migrate raw fetch calls. It is meant to abstract the fetch logic to the parent class so the subclasses only have to worry about the specific details of the resource they represent.

Does that make sense?

[Montekkundan]

@HenriRabalais ahh i see, thanks for clarifying. I pushed follow-up commits to align with the structure!
Let me know if there is anything else to adjust thanks!

[HenriRabalais]

Great! I'll take a look now. Let me know if you have any trouble getting the Client subclasses to work.