Forked project/merging back changes

[mspae]

Hello @egeriis

I forked and customised this code for this framework I'm building. In addition I've also implemented a component for editing JSON:API data. (https://github.com/1xINTERNET/drupal-editable/tree/master/packages/core/src/components)

I'm not sure if my use case is too specific to be able to merge back any changes into this repo. But I think especially the editing component might be of interest for this project.

[egeriis]

So cool! This is by far done, I may even have some additional commits on my computer, that I haven't pushed.

The editing component is a super cool idea!

If you feel like contributing here too, that's very welcome, I think we need to establish some kind of roadmap though. Just so we're moving in the same direction within the same vision.

[egeriis]

Yeah, there were some significant improvements that I hadn't pushed. Pretty cool response caching implemented.

[mspae]

So I think there are two considerable API differences between our implementations:

1. My Query component expects bundle, type and uuid – This is an implementation detail which could easily be put into a parent component.
2. The DataSet child function is called with data instead of resources – I did this to make it feel more graphQL-y and modern. But this is also not a hard requirement. I wanted to keep it as generic as possible and data seemed to be the most unassuming.

Apart from that there are some feature differences which I think the other implementation would benefit from too:

editable implementation

• QueryCache

reduxJsonApi implementation

• apiIsReady flag – I think there is no API access without a baseUrl so a selector like this would make sense. For some API configuration there might be latency (as seen here https://github.com/1xINTERNET/drupal-editable/blob/master/packages/core/src/utils/createStore.js) – and if there isn't this selector won't incur a considerable perf penalty.
• EditableEntity
• refetch callback passed to the children functionx

I'm also thinking about other features which I want to add and which might also be interesting for this library:

• Query component should allow for more complex query strings Query component should allow for more complex query strings 1xINTERNET/drupal-editable#4 – This could also be solved with a wrapper component which handles this but since query strings are part of the JSON:API spec IMHO this could also be a useful addition to reduxJsonApi core
• Query component should accept initial data Query component should accept initial data instead of fetching on mount  1xINTERNET/drupal-editable#5 – As this framework I'm building is supposed to mainly be used in progressive decoupling it would make sense to provide initial data so there isn't an unnecessary API request at the start. I think this would be pretty trivial to do with hydrateStore
• There should be a good way to delete an entity Provide functionality to delete entity 1xINTERNET/drupal-editable#3 - I think this would probably best be solved with a delete callback passed to the children function of EditableEntity
• Same goes for creating a new entity Provide component to create new entity 1xINTERNET/drupal-editable#2

[mspae]

I think in general there should be a consistent nomenclature: data OR resources OR entities – I think "entity" is a purely Drupal thing in this context so maybe it would be best to just use resources (f.x. as argument for the children function in Query and to name the editable component EditableResource) and stick to the JSON:API nomenclature.

[egeriis]

apiIsReady flag – I think there is no API access without a baseUrl so a selector like this would make sense

That is an interesting implementation. I'm curious, is the application ready to be rendered at all, when the store hasn't been created yet? In your case, for instance.

EditableEntity

I still think this is a great idea 🙂

refetch callback passed to the children functionx

I assume this is some kind of reload function? I.e. load from original endpoint again. I implemented links yesterday to allow easy navigation between pages of data. Next up would be "refetch", both of current endpoint and original endpoint (since paginating behind the scenes change the endpoint, thus result set).

Query component should allow for more complex query strings

Something I thought of as late as this morning. This would be great!

Query component should accept initial data

Absolutely. I've been giving this some thoughts too, as this is a requirement to do SSR. Need some way of bootstrapping data across Query usages. Apollo Client has an interesting approach to solving this.

• There should be a good way to delete an entity - I think this would probably best be solved with a delete callback passed to the children function of EditableEntity
• Same goes for creating a new entity

Agree.

I think in general there should be a consistent nomenclature: data OR resources OR entities

In terms of json:api, they're called resources, so I think that's the only valid name to use. data is vague, entity is similar, but confusing 🙂

[mspae]

That is an interesting implementation. I'm curious, is the application ready to be rendered at all, when the store hasn't been created yet? In your case, for instance.

The store is already initialized. The apiIsReady is a selector which returns true if there is correct axiosConfig to connect with the endpoint(s). In my case, it actually prefetches a CSRF token. That's why this is asynchronous.

refetch basically allows refetching whatever was loaded on componentDidMount (Supposed to be analogous to the GraphQL feature). Not sure how this fits in with the links feature. Can you write some example code how the links would be used in the real world?

So I would image the query strings to just be a queryString prop for the Query component which may contain an object which is serialised into a string and appended to the endpoint.

Regarding SSR, there are two ways to go about this AFAIK:

• Simple: inject data into the Query component with a prop. Only fetch on componentDidMount if there is no data.
• More advanced: Provide some kind of global store (QueryCache?) of resources which can be used by the to load data.

Me, I would prefer the second one but. Would we use a pre-hydrated QueryCache for this?

Okay, resources it is 👍

[egeriis]

In my case, it actually prefetches a CSRF token. That's why this is asynchronous.

Right, but your createStore function doesn't return before that API request has completed. I think that's what made me stumble a bit on the need for apiIsReady.

In any regard, I think checking for an axios config is a bit of an anti-pattern to determine if redux-json-api is set up. But I may be misunderstanding something 🙂

refetch basically allows refetching whatever was loaded on componentDidMount

Gotcha. Yeah, I imagine implementing refetch, not only for the initial endpoint, but also for the current endpoint. The current endpoint may be different, due to the implementation of links.

Regarding links, I've pushed some updated to the example repo, where I've implemented links usage.

Regarding SSR, there are two ways to go about this AFAIK

I definitely prefer a global store. The reason being that don't have to carry data down your React tree to the correct component. It can also easily instil healthy design pattern in users' applications, because they don't have to invent their own conventions of storing this initial data.

Would we use a pre-hydrated QueryCache for this?

Something like this 🙂

[mspae]

Right, but your createStore function doesn't return before that API request has completed. I think that's what made me stumble a bit on the need for apiIsReady.

True. 😜 But actually I think that is a problem with my implementation. The createStore should return before the token is there because this async API operation is blocking the initialisation of the whole redux store. But you're right, having this flag is probably not the right way to solving this particular problem. Maybe we could add a skip prop similiar to apollo, which basically disabled autofetching on componentDidMount. This way I could instead use refetch when the apiIsReady selector returns true.

Gotcha. Yeah, I imagine implementing refetch, not only for the initial endpoint, but also for the current endpoint. The current endpoint may be different, due to the implementation of links.

I just saw you pushed this functionality – The currently active links endpoint is not being cached in component state currently, right? Maybe there could be an activeEndpoints state property which initially only contains the original prop endpoint but if call a link load function that URL is also added. When you call refetch it reloads all the endpoints cached in there and thus replaces the resources contained in the responses?

I definitely prefer a global store.

So we can already hydrate the store with resources. We just need to provide a cache which maps endpoints to resource JSONAPIResourceIdentifiers. IMO the QueryCache would be the right place to add this to but I'm not sure because that feature is part of this project (the react lib) but having SSR capabilities would be great to have in the redux/core part of the lib. What do you think?

[egeriis]

The currently active links endpoint is not being cached in component state currently, right?

Yeah, they are cached if caching is enabled.

When you call refetch it reloads all the endpoints cached in there and thus replaces the resources contained in the responses?

Actually not. That's a good catch, we probably want to clear the entire cache. At least optionally.

We just need to provide a cache which maps endpoints to resource JSONAPIResourceIdentifiers. IMO the QueryCache would be the right place to add this to

QueryCache already exists. But it's only used when client-side caching is enabled for a particular Query instance. Thus I don't think it will be the right place, unless we add some read-once ability. Another way to do it is how Apollo Client is handling this, by having an instance of their client which is sent through the React tree using context. Not sure I think it's the most clean solution though.

having SSR capabilities would be great to have in the redux/core part of the lib. What do you think?

This is already possible through the hydrateStore action. So I don't think we need to change anything there.