Apollo Client readFragment with custom id (keyFields) - reactjs

For ref, using "#apollo/client": "^3.5.5",
I've defined my typePolicies like so as suggested in docs:
HistoricalData: {
keyFields: ["variable", "workspace"],
fields:{...}
}
and when my cache is built, I am expecting my cacheId to be like
<__typename>:<id>:<id>
HistoricalData:${props.variable}:${props.workspace}`;
but instead, when I look in the Apollo cache, it's been created using the keyField names and the values in an object, such as
HistoricalData:{"variable":"GAS.TOTAL","workspace":"ABC"}
instead of
HistoricalData:GAS.TOTAL:ABC
so when I try to readFragment it returns null
client.readFragment({
id: `HistoricalData:${props.variable}:${props.workspace}`,
fragment: apolloGQL`fragment MyHistorical on Historical {
variable
workspace
}`})
It does actually return a value from the cache if I create my id in the structure that exists in the cache and readFragment using this.
Has anyone else noticed that Apollo client is not creating the cache id's in the structure that they describe in the docs?

After some research I came upon the correct way to handle this case. I know that you have already moved on, but just in case anyone else has the same problem in the future, here goes:
As described in the documentation for customizing the cache ID, the cache ID will be an stringified object, as you pointed out. It's not quite explicit in the documentation, but at this point in time it provides this nested example for a cache ID:
Book:{"title":"Fahrenheit 451","author":{"name":"Ray Bradbury"}}
But as users we don't have to preoccupy us with the format of this ID, because there's a helper for that, called cache.identify.
For your specific case, you could use something like this:
const identifiedId = cache.identify({
__typename: 'HistoricalData',
variable: 'GAS.TOTAL',
workspace: 'ABC'
});
cache.readFragment({
id: identifiedId,
fragment: apolloGQL`fragment MyHistorical on Historical {
variable
workspace
}`
});

Related

Query based on multiple filters in Firebase

I am working out the structure for a JSON database for an app like onlyFans. Basically, someone can create a club, then inside of that club, there are sections where the creator's posts are shown and another where the club members posts are shown. There is however a filter option where both can be seen.
In order to make option 1 below work, I need to be able to filter based on if isFromCreator=true and at the same time based on timstamp. How can I do this?
Here are the 2 I have written down:
ClubContent
CreatorID
clubID
postID: {isFromCreator: Bool}
OR
creatorPosts
postID: {}
MemeberPosts
postID: {}
Something like the below would be what I want:
ref.child("Content").child("jhTFin5npXeOv2fdwHBrTxTdWIi2").child("1622325513718")
.queryOrdered(byChild: "timestamp")
.queryLimited(toLast: 10)
.queryEqual(toValue: true, childKey: "isFromCreator")
I triedqueryEqual yet it did not return any of the values I know exist with the configuration I specified.
You can use additional resource locations within rules by referencing the parent/child directories specifically and comparing the val() of the respective node structure.
for example:
".write": "data.parent().child('postID').child('isFromCreator').val()"
Just be aware that Security Rules do not filter or process the data in the request, only allow or deny the requested operation.
You can read more about this from the relevant documentation:
https://firebase.google.com/docs/database/security/rules-conditions#referencing_data_in_other_paths
https://firebase.google.com/docs/database/security/core-syntax#rules-not-filters

cache.writeFragment method in graphQL apollo library doesn't work

I'm trying to add a property to an object already in cache.
I have added local resolver and in that i'm doing this.
cache.writeFragment({
id: gid.toString(),
fragment: gql`
fragment queues on Group {
queuesList
}
`,
data: {
queuesList: ["test"],
__typename: "Group"
}
});
This writes an object to cache and does not add a property to object of given Id.
I don't understand where does fragment fail.
Okay, I was doing it wrong.
I was giving fragment wrong id, I had to pass the object keys in cached data.
That is. id: Group:${gid.toString()}
https://www.apollographql.com/docs/react/caching/cache-configuration/#generating-unique-identifiers
Hope this helps anyone in same situation.

Setting arrays in Firebase using Firebase console

I am using Firebase console for preparing data for a demo app. One of the data item is attendees. Attendees is an array. I want to add a few attendees as an array in Firebase. I understand Firebase does not have arrays, but object with keys (in chronological order). How do I do that for preparing sample data? My current Firebase data looks like the below.
The Firebase Database doesn't store arrays. It stores dictionaries/associate arrays. So the closest you can get is:
attendees: {
0: "Bill Gates",
1: "Larry Page",
2: "James Tamplin"
}
You can build this structure in the Firebase Console. And then when you read it with one of the Firebase SDKs, it will be translated into an array.
firebase.database().ref('attendees').once('value', function(snapshot) {
console.log(snapshot.val());
// ["Bill Gates", "Larry Page", "James Tamplin"]
});
So this may be the result that you're look for. But I recommend reading this blog post on why Firebase prefers it if you don't store arrays: https://firebase.googleblog.com/2014/04/best-practices-arrays-in-firebase.html.
Don't use an array, when you actually need a set
Most developers are not actually trying to store an array and I think your case might be one of those. For example: can "Bill Gates" be an attendee twice?
attendees: {
0: "Bill Gates",
1: "Larry Page",
2: "James Tamplin",
3: "Bill Gates"
}
If not, you're going to have to check whether he's already in the array before you add him.
if (!attendees.contains("Bill Gates")) {
attendees.push("Bill Gates");
}
This is a clear sign that your data structure is sub-optimal for the use-case. Having to check all existing children before adding a new one is going to limit scalability.
In this case, what you really want is a set: a data structure where each child can be present only once. In Firebase you model sets like this:
attendees: {
"Bill Gates": true,
"Larry Page": true,
"James Tamplin": true
}
And now whenever you try to add Bill Gates a second time, it's a no-op:
attendees["Bill Gates"] = true;
So instead of having to code for the uniqueness requirement, the data structure implicitly solves it.
To add arrays manually using Firebase Realtime DB console:
Use double " " instead of single ' ' quotes
Which provides this structure:
After writing my other answer I realized that you might simply be looking how to add push IDs in the console.
That's not a feature at the moment. Most of is either use different types of keys when entering test data or have a little JavaScript snippet in another tab to generate the keys and copy/paste them over.
Please do request the feature here, since you're definitely not the first one to ask.
firebase array ?yeah, i have same problem with you few weeks ago, but i found it in here. Finally i can use it with my ChartJS.
function jamToArray(snapshot) {
const returnArr = [];
snapshot.forEach(function(childSnapshot) {
const item = childSnapshot.val().time;
returnArr.push(item);
});
return returnArr;
};
firebase.database().ref('sensor').limitToLast(10).on('value', function(snapshot) {
const jam = jamToArray(snapshot);
});

Relay mutation. FatQuery. Ask all fields in REQUIRED_CHILDREN

My question is: i have a mutations config where i have a REQUIRE_CHILDREN config with children array of queries. How can i get all possible fields from a payload object?
{
type: 'REQUIRED_CHILDREN',
children: [
Relay.QL`
fragment on MyPayload {
me {
id
...others field
}
}`]
So how can i ask all possible fields from me object? If i point only fragment on MePayload { me } object relay still returns me me { id }. I want relay to return me all fields in me object. Thanks.
You can't - your client code needs to specify all the fields you want to fetch explicitly. Those fields are then statically validated by the babel-relay-plugin, etc.
You probably don't want to be using REQUIRED_CHILDREN either, by the way. That's only useful to fetch fields that are only accessible in the onSuccess callback of the mutation, and therefore are never written to the Relay store and accessible to Relay containers...

An approach to deal with dependency resolution and optimistic updates in react applications

In an architecture where objects have many complex relationships, what are some maintainable approaches to dealing with
Resolving Dependencies
Optimistic Updates
in react applications?
For example, given this type of schema:
```
type Foo {
...
otherFooID: String,
bars: List<Bar>
}
type Bar {
...
bizID: String,
}
type Biz {
...
}
```
A user might want to save the following ->
firstBiz = Biz();
secondBiz = Biz();
firstFoo = Foo({bars: [Bar({biz: firstBiz})]
secondFoo = Foo({bars: [Bar({biz: secondBiz})] otherFooId: firstFooId.id})
First Problem: Choosing real ids
The first problem with above is having the correct id. i.e in order for secondFoo to save, it needs to know the actual id of firstFoo.
To solve this, we could make the tradeoff, of letting the client choose the id, using something like a uuid. I don't see anything terribly wrong this this, so we can say this can work
Second Problem: Saving in order
Even if we determine id's from the frontend, the server still needs to receive these save requests in order.
```
- save firstFoo
// okay. now firstFoo.id is valid
- save secondFoo
// okay, it was able to resolve otherFooID to firstFoo
```
The reasoning here is that the backend must guarantee that any id that is being referenced is valid.
```
- save secondFoo
// backend throws an error otherFooId is invalid
- save firstfoo
// okay
```
I am unsure what the best way to attack this problem is
The current approaches that come to mind
Have custom actions, that do the coordination via promises
save(biz).then(_ => save(Bar).then(_ => save(firstFoo)).then(_ => save(second)
The downside here is that it is quite complex, and the number of these kinds of combinations will continue to grow
Create a pending / resolve helper
const pending = {}
const resolve = (obj, refFn) => {
return Promise.all(obj, refFn(obj));
}
const fooRefs = (foo) => {
return foo.bars.map(bar => bar.id).concat(foo.otherFooId);
}
pending[firstFoo].id = resolve(firstFoo, fooRefs).then(_ => save(firstFoo))
```
The problem with 2. is that it can cause a bunch of errors easily, if we forget to resolve or to add to pending.
Potential Solutions
It seems like Relay or Om next can solve these issues, but i would like something less high power. Perhaps something that can work in with redux, or maybe it's some concept I am missing.
Thoughts much appreciated
I have a JS/PHP implementation of such a system
My approach is to serialize records both on the client and server using a reference system
For example unsaved Foo1 has GUID eeffa3, and a second Foo references its id key as {otherFooId: '#Foo#eeffa3[id]' }
Similarily you can reference a whole object like this
Foo#eefa3:{bars['#Baz#ffg4', '#Baz#ffg5']}
Now the client-side serializer would build a tree of relations and model attributes like this
{
modelsToSave:[
'Foo#effe3':{
attribs:{name:'John', title:'Mr.'},
relations:{bars:['#Bar#ffg4']}
},
'Bar#ffg4':{
attribs:{id:5}
relations:{parentFoo:'#Foo#effe3'}
},
]
}
As you can see in this example I have described circular relations between unsaved objects in pure JSON.
The key here is to hold these "record" objects in client-side memory and never mutate their GUID
The server can figure out the order of saving by saving first records without "parent" dependencies, then records which depend on those parents
After saving, the server wil return the same reference map, but now the attribs will also include primary keys and foreign keys
JS walks the received map twice (first pass just update server-received attributes, second pass substitute record references and attribute references to real records and attributes).
So there are 2 mechanisms for referencing a record, a client-side GUID and a server-side PK
When receiving a server JSON, you match your GUID with the server primary key

Resources