Skip to content
This repository has been archived by the owner on Mar 20, 2022. It is now read-only.

Added recursive dependencies support for denormalize method #220

Merged
merged 3 commits into from Jan 30, 2017
Merged

Added recursive dependencies support for denormalize method #220

merged 3 commits into from Jan 30, 2017

Conversation

maxsbelt
Copy link
Contributor

Problem

denormalize method doesn't support recursive linked entities.

Solution

__cache key is added to entities object parameter for keeping already visited entities. The same approach is already used in denormalizr package.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling c1fa0ec on maxsbelt:denormalize-resursive into e365e51 on paularmstrong:master.

Copy link
Owner

@paularmstrong paularmstrong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking into this! Unfortunately, it doesn't work for me, as-is. I'd like to see another pass that removes the reserved __cache key from entities and not pushing an empty object in place of something that would be recursive. I'd expect to see the ID left in place.

"reports": Array [
Object {
"title": "Weekly report",
"user": Object {},
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect this to be the user's ID, not an empty object. I don't think this is actually working the way you want.

}

if (!entities.__cache[skey][object[key]]) {
entities.__cache[skey][object[key]] = {};
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line is unnecessary since you're definiting a value for it on the next line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually this line block the recursion, but I agree with you that {} is unexpected value. Fixed this by passing object from entities to it.

if (Array.isArray(object[key])) {
object[key] = unvisit(object[key], localSchema, entities);
} else {
const skey = localSchema.key;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does skey stand for? No need to shorten variable names and sacrifice clarity.

@@ -72,5 +72,6 @@ export const denormalize = (input, schema, entities) => {
return input;
}

entities = { ...entities, __cache: {} };
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like adding a reserved key here. There's no reason someone might have a __cache entity. (I know, it's not the best name for an entity, but I'd hate to ruin someone's day if they tried to use it).

I'd rather see a separate visitedEntities cache object passed around than using reserved keys.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling eaa68e8 on maxsbelt:denormalize-resursive into e365e51 on paularmstrong:master.

title: 'Weekly report',
user: 1
},
2: {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you have all of this extra setup data (report 2, user 2). Can delete since it's not being used.

@@ -33,6 +33,26 @@ Object {
}
`;

exports[`denormalize denormalizes recursive dependencies 1`] = `
Object {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My expected output would be:

{
  title: "Weekly report",
  user: {
    role: 'manager',
    reports: [ 1 ]
  }
}

This is going too many levels deep and isn't properly keeping track of the fact that we've already come across report 1.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's reasonable. I changed denormalization logic to confirm described expectations. Please, review last commit.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 064ae64 on maxsbelt:denormalize-resursive into e365e51 on paularmstrong:master.

Copy link
Owner

@paularmstrong paularmstrong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for getting this together, and great work, @maxsbelt!

I'm going to merge this and do a tiny bit of refactoring to make this work a little more like the reverse of addEntities from the normalization process so that the logic for tracking what entities has been visited is centralized outside of the schemas.

@paularmstrong paularmstrong merged commit 064ae64 into paularmstrong:master Jan 30, 2017
@maxsbelt maxsbelt deleted the denormalize-resursive branch January 30, 2017 20:54
paularmstrong added a commit that referenced this pull request Feb 10, 2017
@lock
Copy link

lock bot commented May 7, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot added the Outdated label May 7, 2018
@lock lock bot locked as resolved and limited conversation to collaborators May 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
3 participants