How can platform-independent libraries depend on the client?

[RubenVerborgh]

I'm opening this issue in response to this comment:

Due to the architectural changes leading the lib not to be isomorphic anymore, this is no longer relevant.

---

We have a couple of JavaScript libraries that will use this client in order to interface with Solid pods. Some of those libraries can run either on the client (browser, native, …), the server (Node.js, …), or an intermediary (Node.js, …). Concretely, I'm thinking about libraries such as:

• rdflib.js
• Comunica
• LDflex
• …

These libraries, which themselves do not commit to a platform, need to depend on a generic notion of a Solid client. Only when these libraries are used by a concrete application, they will be bound to a concrete platform by that application.

If not via isomorphism, how are we going to achieve this? Very concretely, what do I as a builder of platform-agnostic Solid libraries put in my package.json?

[Vinnl]

At the moment there is no support for running in an environment other than the browser, unfortunately. We do hope to provide an alternative that runs in Node in the not too distant future (this is not a promise though :) ), at which point such a library could decide which package to use at runtime - we might even provide a package that does so for you.

Alternatively, you can take the approach we have with solid-client, which means accepting a fetch function as an injected dependency. The developer can then construct it using the package applicable to their environment, if and when such a package is available.

In fact, unless solid-client-authn-browser is updated to support a default session (@NSeydoux, do we have a (public) ticket for that?), this will be required anyway: unless the library is in charge of the sign-in flow, it will not be able to obtain the session by itself.

But to answer your question:

Very concretely, what do I as a builder of platform-agnostic Solid libraries put in my package.json?

Nothing, for now.

[nicolasmondada]

Hi @RubenVerborgh,

Thanks for your feedback. I understand your concerns and we are always looking for better ways to help developers extend and build on top of Inrupt libraries.

Let's have a chat offline and discuss how we can better support you and others like you.

Cheers, Nick.-

[jeff-zucker]

Needless to say, I am keeping my fingers crossed for a nodejs version, please let me know if I can help testing or otherwise. I am very much in favor of "accepting a fetch function as an injected dependency". This works well for including solid-rest in rdflib and in conjunction with solid-client-authn-browser. May I suggest that if this is the way things go, that you use the same variable name as rdflib which looks for window.solidFetcher (and global.solidFetcher for nodejs) as well as accepting an alternate fetch method on construction of a fetcher.

[rubensworks]

Hi all 👋

I'm currently looking into incorporating this library in to the Comunica framework, and I was wondering if there's any news regarding this issue that has not been mentioned here yet?

If there's no concrete solution yet, I can recommend following an approach similar to the cross-fetch package. This could involve creating a package such as @inrupt/solid-client-authn-isomorphic that essentially just acts as a wrapper on top of the Node and browser versions. By default, this package could point to the Node version, and when this package is used in browser apps, it could automatically redirect to the browser version via the "browser" package.json entry (just like cross-fetch does).

Platform-environment packages could then just depend on the @inrupt/solid-client-authn-isomorphic, and things would work automatically within Node and browser environments.

I'm happy to help out if needed!

[NSeydoux]

Hi Ruben,

Thanks for the suggestion, I'll give it a try ! Do you know if it would still enable tree-shaking if the final app is in a browser context ? Otherwise that may result in a somewhat heavy module ^^.

[rubensworks]

Do you know if it would still enable tree-shaking if the final app is in a browser context ?

It should still enable tree-shaking AFAIK. (at least this works when I follow this approach)

[rubensworks]

For reference, I just created a small isomorphic package here: https://github.com/rubensworks/solid-client-authn-isomorphic.js I published it under my personal scope on npm, as I consider it to be temporary package. Happy to deprecate it once isomorphic support lands in this repo here. (Also happy to submit a PR to this repo if you think this is the right approach)

I thought it might be valuable for others that want to use something in the meantime 🙂