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
Conversation
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 |
@NikitaSedyx Yes, you're right, "refactoring" is changing the code without altering functionality. |
react-query
react-query
plz avoid code smells |
Test errors found for test. See https://jenkins-aws.indexdata.com/job/folio-org/job/ui-remote-storage/job/PR-68/17/ |
…UIRS-33-1 # Conflicts: # CHANGELOG.md
@@ -0,0 +1,90 @@ | |||
import { useQueryClient } from 'react-query'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is elaborate article on the subject https://badgerbadgerbadgerbadger.medium.com/letter-casing-in-names-of-imported-nodejs-modules-707194c6a003
|
||
import { useOkapiQuery } from './useOkapiQuery'; | ||
import { useOkapiMutation } from './useOkapiMutation'; | ||
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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(() => { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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/
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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'; | ||
|
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 )
There was a problem hiding this 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(() => { |
There was a problem hiding this comment.
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.
Kudos, SonarCloud Quality Gate passed! |
Good job, like how you used |
https://issues.folio.org/browse/UIRS-33
Purpose
Approach
react-query
instead of Stripes connectTODOS and Open Questions
providers
codemoment
alternativePre-Merge Checklist
Before merging this PR, please go through the following list and take appropriate actions.
If there are breaking changes, please STOP and consider the following:
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.