Recent history cards display variable names rather than values

[actuallyyun]

Steps to Reproduce

1.Go to edit page https://openbeta.io/edit 2.in the Recent history component, the cards for each history entry are displaying variable names such as

updatedBy.sub_type
updatedBy.buffer
updatedBy.position
metadata.isBoulder
metadata.leaf
metadata.lnglat.type
metadata.lnglat.coordinates[0]
metadata.lnglat.coordinates[1]

Screenshots

Expected Behavior

Maybe it should show meaningful values of these variables.

Current Behavior

Currently, it does not provide meaningful information. I am not sure if this is intended. If not, I could try to fix it.

Browser & version

<--- Example: Firefox 102.7.0esr --> Chrome

Operating system

<--- Example: MacOS 13.2.1 -->

[actuallyyun]

Currently, in the history query result, the UpdatedFields only contain fields and thus were shown on the history cards.

for instance: 
updatedFields
: 
Array(50)
0
: 
"_change.user.sub_type"
1
: 
"_change.user.buffer"
2
: 
"_change.user.position"
3
: 
"_change.historyId"
4
: 
"_change.prevHistoryId"
5
: 
"_change.operation"
6
: 
"_change.seq"
7
: 
"climbs[0].sub_type"
8
: 
"climbs[0].buffer"
9
: 
"climbs[0].position"
10
: 
"climbs[1].sub_type"
11
: 
"climbs[1].buffer"
12
: 
"climbs[1].position"
13
: 
"climbs[2].sub_type"
14
: 
"climbs[2].buffer"
15
: 
"climbs[2].position"
16
: 
"climbs[3].sub_type"
17
: 
"climbs[3].buffer"
18
: 
"climbs[3].position"

To fix this, it seems like it should be done in the db. What do you think?

[vnugent]

Listing changed field names was a temporary solution. Maybe we can display the field value instead?

[andrew-jp]

I'll check this out

[andrew-jp]

This is a little complicated. It seems like the most obvious option would be to pass in the edited field to the change history. This would add a little data to the pipeline and DB, but we would avoid additional queries. At a low level, we have an object consisting of: { updatedFields: [], removedFields: [], truncatedArrays: [] }

The updatedFields attribute is the only one used by the front end in this situation. We could change the way we store changes - saving a tuple like (field, old, new) i.e. ("length", 30, 34) or just (field, new), instead of just the field. This would allow a prettier display of the edit cards by just printing out the tuples however we want. It might also mean updating all 3 layers of the backend, along with a lot of excess stored data that exists elsewhere (until it's changed again, then the old version would be saved in the logs).

Another option, although one I don't understand completely, is passing/pulling the updated fields in the "fullDocument" that gets stored along with the change.

This is in "RecentChangeHistory.tsx -> ClimbChange()" where the data is being organized for the edit cards. const { name, id } = fullDocument as ClimbType

The AreaType/ClimbType used in this file are the full types - with length, description, FA etc.

Could we do some magic here and pull the updated fields? Something like: const {name, id, {...updateFields}} = fullDocument as ClimbType to form something like: const {name, id, length, protection} = fullDocument as ClimbType

I tried the above, just adding 'yds' and 'length' into the object copying above, but it looked like I couldn't get any data out of it. I'm guessing only a partial document with the name and id is passed in, but haven't figured out where this happens.

Any advice/thoughts would be appreciated!

[vnugent]

You can add additional fields to fullDocument in the GQL query (I'd recommend playing with the schema in an online GQL explorer)

https://github.com/OpenBeta/open-tacos/blob/develop/src/js/graphql/gql/contribs.ts#L112

Unfortunately, fullDocument only contains post-edit data, what the new changes are. In order to get the 'before data' to create a nice visual diff, we would need add additional queries to the backend.

[andrew-jp]

That was what I needed. Here's a sample

[vnugent]

Great! We can do full visual diffs (similar GitHub code diff'ing for example) in the future.