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

Fix a slew of Node.js tests and regenerate some snippets #3352

Merged
merged 8 commits into from
Aug 6, 2024

Conversation

krollins-mdb
Copy link
Collaborator

@krollins-mdb krollins-mdb commented Jul 31, 2024

Pull Request Info - SDK Docs Consolidation

This PR mostly fixes fixes tests, but made some snippet changes for a couple of pages too.

Release Notes

  • Mostly internal: Node SDK
    • Fixed failing tests

- update counters tests
- Change schema property id to object id
- Fix find predicate
- Add JS quickstart test
- Update quickstart to use new generated snippets
@krollins-mdb krollins-mdb added the Add to consolidation feature branch PR merged after cutting the consolidation feature branch, so cherry-pick to the feature branch. label Jul 31, 2024
Copy link

netlify bot commented Jul 31, 2024

Deploy Preview for device-sdk ready!

Name Link
🔨 Latest commit d569cb8
🔍 Latest deploy log https://app.netlify.com/sites/device-sdk/deploys/66b244e4c4865f000854aabb
😎 Deploy Preview https://deploy-preview-3352--device-sdk.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse
1 paths audited
Performance: 32 (🔴 down 1 from production)
Accessibility: 93 (no change from production)
Best Practices: 75 (no change from production)
SEO: 69 (no change from production)
PWA: -
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link

github-actions bot commented Jul 31, 2024

Readability for Commit Hash: d569cb8

You can see any previous Readability scores (if they exist) by looking
at the comment's history.

Readability scores for changed documents:

  • source/sdk/node/quick-start: Grade Level: 8.8, Reading Ease: 51.85
  • source/sdk/node/model-data/data-types/counters: Grade Level: 8.2, Reading Ease: 58.79

For Grade Level, aim for 8 or below.

For Reading Ease scores, aim for 60 or above:

Score Difficulty
90-100 Very Easy
80-89 Easy
70-79 Fairly Easy
60-69 Medium
50-59 Fairly Hard
30-49 Hard
0-29 Very Hard

For help improving readability, try Hemingway App.

@krollins-mdb krollins-mdb marked this pull request as ready for review July 31, 2024 20:41
Copy link
Collaborator

@dacharyc dacharyc left a comment

Choose a reason for hiding this comment

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

Handful of Qs here, but none of them are blocking. Thanks for fixing up these tests!

import Realm, { BSON } from "realm";

// :snippet-start: declare-counter-schema
export class ClassWithCounter extends Realm.Object {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a nitpick and I know we haven't had a chance to discuss code example style stuff, but I really prefer to avoid arbitrary names like ClassWithCounter. I'd rather we used an actual real-world use case name and example. I don't want there to be any misunderstanding about whether there is required usage stuff encoded in our naming in the code examples. (I.e. someone seeing something called ClassWithCounter or counterProperty and thinking the naming somehow has to match that in order to use this functionality.)

So maybe this could be something like SiteVisitTracker or something where a counter would make sense logically, but doesn't directly tie in with the naming of the thing?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, I agree. I was struggling with determining how much to change the stuff Omar added. I think I ended up in a weird middle ground. I'll update the class and property names.

// :snippet-end:

// :snippet-start: define-an-object-model
export class QuickstartTask extends Realm.Object {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Presumably the export here is related to the fact that we're including these models here in this file, but using them somewhere else in the code.

Just wondering if we actually want to show this as part of our class declarations, or should we declare the class here and then export it later outside of this snippet?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Generally, yes. Best practice with the JS SDK is to define models in a separate file from where you use them. So, the default should export/import.

Worth questioning here though. In the Reactive Native docs, the standard is pretty well established. I don't think as clear in the Node docs. I'll think about this a bit more.

describe("Quickstart Sync", () => {
test("should open a Flexible Sync realm with initial subscriptions", async () => {
// :snippet-start: open-realm-with-subscriptions
// :replace-start: {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, this is probably another thing we should discuss as part of our code example style convo. In other SDKs, we've had the convention of declaring the "replace" block at the start of the file. I would not have expected to find one in the middle of the file, and so if I didn't see it at the top I would have assumed there wasn't one in this file.

We can bikeshed over which is better, but I think it would be good to agree to a convention as a team and follow it, so we can have consistent expectations about where to find things in each SDK's test suite.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Happy to standardize - though I don't think any of the JS docs have ever done that. 😅

.objects(QuickstartTask)
.filtered(`owner_id == "${anonymousUser.id}"`);

expect(assignedTasks.length).toBe(0);
Copy link
Collaborator

Choose a reason for hiding this comment

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

In some of the other sync quick starts, we actually write stuff, verify it uploaded, and then delete it.

Should we do that in this test?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Probably. If I don't have time to do it in this PR, I'll create a Jira ticket so that the work is documented.


.. literalinclude:: /examples/generated/node/data-types.test.snippet.initialize-counter.js
:language: javascript
.. include:: /examples/generated/node/v12/formatted/data-types.test.snippet.initialize-counter.ts.rst
Copy link
Collaborator

Choose a reason for hiding this comment

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

We may want to discuss how to handle these things going forward, but for the consolidated world, seeing only a .ts file here would make me say the JS examples are missing. I would put in a "missing placeholder" for the JS.

If we choose not to maintain two separate snippets because the code would be the same in JS and TS, can we use some sort of naming convention to make it clear to folks who don't regularly do JS and TS dev stuff that this snippet works for both?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good point. Yeah, we'll need something. JS tests should be TypeScript first, even when there isn't any TypeScript code. The reasoning being that the compiler can catch all sorts of errors with plain ol' JS.

I'll do some thinking on this one too.

@krollins-mdb krollins-mdb merged commit be7913a into mongodb:master Aug 6, 2024
12 checks passed
@krollins-mdb krollins-mdb deleted the node-tests-exploration branch August 6, 2024 15:50
@docs-builder-bot
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Add to consolidation feature branch PR merged after cutting the consolidation feature branch, so cherry-pick to the feature branch.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants