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

UIRS-33 Major rework using react-query #68

Merged
merged 35 commits into from Jun 1, 2021
Merged

UIRS-33 Major rework using react-query #68

merged 35 commits into from Jun 1, 2021

Conversation

axelhunn
Copy link
Contributor

@axelhunn axelhunn commented May 20, 2021

https://issues.folio.org/browse/UIRS-33

Purpose

  • Refresh the list after the configuration has been edited
  • Fix other API-related quirks
  • Refactor the code structure

Approach

  • Use react-query instead of Stripes connect
  • Introduce API abstractions
  • Move route-related stuff to one place, top-level
  • Set up integration tests

TODOS and Open Questions

  • refactor the providers code
  • improve test coverage
  • use moment alternative

Pre-Merge Checklist

Before merging this PR, please go through the following list and take appropriate actions.

  • I've added appropriate record to the CHANGELOG.md
  • Does this PR meet or exceed the expected quality standards?
    • Code coverage on new code is 80% or greater
    • Duplications on new code is 3% or less
    • There are no major code smells or security issues
  • Does this introduce breaking changes?
    • If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
    • There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

  • What other modules will these changes impact?
  • Do JIRAs exist to update the impacted modules?
    • If not, please create them
    • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
    • Do they have all they appropriate links to blocked/related issues?
  • Are the JIRAs under active development?
    • If not, contact the project's PO and make sure they're aware of the urgency.
  • Do PRs exist for these changes?
    • If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

package.json Outdated Show resolved Hide resolved
@NikitaSedyx
Copy link
Contributor

suggestion from EBSO team to do refactoring in separate request, in this one you implement list autorefresh (the purpose of the request), but summary is about rafctoring

@axelhunn
Copy link
Contributor Author

@NikitaSedyx Yes, you're right, "refactoring" is changing the code without altering functionality.
I'll change it to "rework".
Thanks for pointing out!

@axelhunn axelhunn changed the title UIRS-33 Major refactor using react-query UIRS-33 Major rework using react-query May 20, 2021
@NikitaSedyx
Copy link
Contributor

plz avoid code smells

@id-jenkins
Copy link

jest.config.js Outdated Show resolved Hide resolved
@@ -0,0 +1,90 @@
import { useQueryClient } from 'react-query';
Copy link
Contributor

Choose a reason for hiding this comment

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

why do your files start from capital? are they classes or components?

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 a composite module, with several exports

Copy link
Contributor

Choose a reason for hiding this comment

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

usually it follows camelCase, PascalCase is used by classes or components

Copy link
Contributor Author

@axelhunn axelhunn May 31, 2021

Choose a reason for hiding this comment

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

I guess there's no strict rule for modules.

As a general rule we use camelCase for something that is insnance and can be multiplied,
and PascalCase for something that can be instantiated OR is used as namespace for static members, like React in

import React from 'react';

class Abc extends React.Component {

They also use the same convention in MDN for module names, see
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#creating_a_module_object

As for naming the files, in React world we use same case for filename as for it content - same PascalCase for components and classes. So I used to name such modules in PascalCase too.

But again, no strict rules for that, it's an opinionated thing.
So if you point me to the rule on this here in FOLIO, I'll gladly abide it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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


import { useOkapiQuery } from './useOkapiQuery';
import { useOkapiMutation } from './useOkapiMutation';

Copy link
Contributor

Choose a reason for hiding this comment

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

is it new style to have 2 empty lines?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

General stripes lint rules added this possibility a while ago.
See https://folio-project.slack.com/archives/C210UCHQ9/p1607449155266300

I guess visual dividing logically separated portions of code is a good thing.
Anything is good if it adds readability.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's enough to have 1 line to have visual dividing logically separated portions of code

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What if portions to be separated have empty lines inside?

Copy link

Choose a reason for hiding this comment

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

I mean, these are mostly just functions and not various heterogenous chunks of code, so I don't really think that applies here. But 🤷, I don't really have a stake in this.


let request;

beforeEach(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

outside describe? is it legal?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, perfectly so.
Took it from this exapmle https://testing-library.com/docs/react-testing-library/example-intro/

Copy link
Contributor

Choose a reason for hiding this comment

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

IMO describe provides more readable message in case of fail

Copy link
Contributor Author

Choose a reason for hiding this comment

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

describe is just a tool for grouping related test.
Test files are the tool for the same purpose.

If the filename clearly tells what the test is about, the message is informative enough
image

Copy link

Choose a reason for hiding this comment

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

What is nice about using describe is that you can filter the entire test file with jest -t "some describe text". Without it it's harder to do.


import { useOkapiQuery } from './useOkapiQuery';
import { useOkapiMutation } from './useOkapiMutation';

Copy link

Choose a reason for hiding this comment

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

I mean, these are mostly just functions and not various heterogenous chunks of code, so I don't really think that applies here. But 🤷, I don't really have a stake in this.

@@ -0,0 +1,55 @@
import React, { useMemo } from 'react';
import { FormattedMessage, useIntl } from 'react-intl';
import moment from 'moment';
Copy link

Choose a reason for hiding this comment

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

I'm trying to not use moment in new code these days given the Moment project's suggestion that you probably shouldn't be using it anymore. At a glance it seems like the vanilla JS libs could satisfy your requirements here - is that the case or did I not dig enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's from the code before. I just left it as-is.
What do we use in folio instead?

Copy link

Choose a reason for hiding this comment

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

Ahhh, hard to tell when it just shows up as a new file in Github! In general, vanilla JS' Date API is good enough for everything I've needed in Folio, beforehand. That link in the comment has some alternatives, including libraries if vanilla isn't good enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess, I'll leave it a tech debt for now.
Too many changes for one PR )

Copy link

@mkuklis mkuklis left a comment

Choose a reason for hiding this comment

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

Nice work @axelhunn!


let request;

beforeEach(() => {
Copy link

Choose a reason for hiding this comment

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

What is nice about using describe is that you can filter the entire test file with jest -t "some describe text". Without it it's harder to do.

@sonarcloud
Copy link

sonarcloud bot commented Jun 1, 2021

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

87.2% 87.2% Coverage
0.0% 0.0% Duplication

@axelhunn axelhunn merged commit b0bc553 into master Jun 1, 2021
@axelhunn axelhunn deleted the UIRS-33-1 branch June 1, 2021 19:22
@ViktorSoroka07
Copy link

Good job, like how you used msw and turned off logs for errored requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants