Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve toJSON functionality and remove JSONSerializerReplacer #4997

Merged
merged 9 commits into from
Oct 12, 2022

Conversation

gagik
Copy link
Contributor

@gagik gagik commented Oct 10, 2022

What, How & Why?

This is a breaking change that removes JSONSerializerReplacer and improves the current toJSON functionality. It also improves current tests, organizing them better and adding cases for dictionaries.
With removal JSONSerializerReplacer, users are advised to use external libraries such as flatted and @ungap/structured-clone if they need to deal with serialising objects with circular references into a JSON string.
The expected functionality of toJSON is therefore to generate valid, plain JavaScript objects with correct circular references so those can be used by the packages mentioned above. toJSON is implemented by Realm Object, Dictionary, and Collection.

Related to #4966.

☑️ ToDos

  • 📝 Changelog entry
  • 📝 Compatibility label is updated or copied from previous entry
  • 📝 Update COMPATIBILITY.md
  • 🚦 Tests
  • 🔀 Executed flexible sync tests locally if modifying flexible sync
  • 📦 Updated internal package version in consuming package.jsons (if updating internal packages)
  • 📱 Check the React Native/other sample apps work if necessary
  • 📝 Public documentation PR created or is not necessary
  • 💥 Breaking label has been applied or is not necessary

If this PR adds or changes public API's:

  • typescript definitions file is updated
  • jsdoc files updated
  • Chrome debug API is updated if API is available on React Native

Copy link
Contributor Author

@gagik gagik left a comment

Choose a reason for hiding this comment

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

Just some things worth noting.

}

const Obj& obj = realm_object->obj();
auto table_key = obj.get_table()->get_key();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This seems like something to address in core: there is a private get_table_key() method which is just a shortcut to this. I think it'd be good to make that method public since I imagine this would be nice to use in contexts like this (and you can access it anyways so no reason not to).

Copy link
Contributor

Choose a reason for hiding this comment

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

That's an interesting observation, and I suggest that you bring it up with the team working on the bindgen project (core's public API is part of the project).

src/js_realm_object.hpp Show resolved Hide resolved
CHANGELOG.md Show resolved Hide resolved
@gagik gagik requested a review from kneth October 10, 2022 12:02
CHANGELOG.md Outdated

### Enhancements
* Small improvement to performance by caching JSI property String object [#4863](https://github.com/realm/realm-js/pull/4863)
* Small improvement to performance for `toJSON` which should make it useful for cases where a plain representations of Realm entities are needed, e.g. when inspecting them for debugging purposes through `console.log(realmObj.toJSON())`.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

not sure if there is more to say / smth different to say.

types/index.d.ts Show resolved Hide resolved
CHANGELOG.md Show resolved Hide resolved
src/js_realm_object.hpp Show resolved Hide resolved
}

const Obj& obj = realm_object->obj();
auto table_key = obj.get_table()->get_key();
Copy link
Contributor

Choose a reason for hiding this comment

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

That's an interesting observation, and I suggest that you bring it up with the team working on the bindgen project (core's public API is part of the project).

},
];
const commonTests: Record<string, TestSetup> = {
//@ts-expect-error subject and serialized are set before tests run.
Copy link
Member

Choose a reason for hiding this comment

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

Can you share a bit more about this? It feels like this could be avoided.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

so, I can either make the subject and serialized fields as optional in which case I won't have this TS error here but then I will have to try to avoid all errors where I use subject but it could be undefined (even though it will never be undefined because it will be set before each test). This was my way of avoiding this but I can see how this is hacky, I can look into alternative

types/index.d.ts Outdated Show resolved Hide resolved
types/index.d.ts Outdated Show resolved Hide resolved
types/index.d.ts Outdated Show resolved Hide resolved
Copy link
Member

@kraenhansen kraenhansen left a comment

Choose a reason for hiding this comment

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

Minor suggestions. Great job @gagik!

Copy link
Contributor Author

@gagik gagik left a comment

Choose a reason for hiding this comment

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

I just realized this PR seems to be updating vendor/real-core? That's odd.

},
];
const commonTests: Record<string, TestSetup> = {
//@ts-expect-error subject and serialized are set before tests run.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

so, I can either make the subject and serialized fields as optional in which case I won't have this TS error here but then I will have to try to avoid all errors where I use subject but it could be undefined (even though it will never be undefined because it will be set before each test). This was my way of avoiding this but I can see how this is hacky, I can look into alternative

@gagik gagik merged commit 6bb0429 into v11 Oct 12, 2022
@gagik gagik deleted the gagik/removejsonreplacer branch October 12, 2022 12:01
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants