-
Notifications
You must be signed in to change notification settings - Fork 81
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
feat: Taxonomy export menu [FC-0036] #645
feat: Taxonomy export menu [FC-0036] #645
Conversation
Thanks for the pull request, @ChrisChV! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
667bf1e
to
09aa8b6
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #645 +/- ##
==========================================
+ Coverage 88.02% 88.40% +0.38%
==========================================
Files 417 424 +7
Lines 6598 6573 -25
Branches 1428 1411 -17
==========================================
+ Hits 5808 5811 +3
+ Misses 765 737 -28
Partials 25 25 ☔ View full report in Codecov by Sentry. |
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.
Hi @ChrisChV! It looks good to me.
- I read through the code
- I followed the test instructions and ran the code locally
About the system-defined taxonomy export that @bradenmacdonald mentioned in the other PR:
We have a restriction in the python API blocking the import/export of system-defined taxonomies. I think the main reason was to avoid importing a system-defined taxonomy (no one can change it), but currently, the same check is applied to both (import/export):
I think it will not be a problem to decouple the checks.
@bradenmacdonald Do you think we should handle it in this task or another later?
@ChrisChV CC @rpenido This repo has good documentation in the README describing its various features and how to enable them. This isn't the first Tagging feature for this repo (#622 was first), but this is the next one likely to merge, so could you update the README to add details for these features (including the platform flags we need to set), and we'll do the same for subsequent Tagging PRs? |
Let's make the change to allow export (not import) of system-defined taxonomies on the backend now. It should be a simple change, and you don't need to include a version bump or anything. Later we can make the corresponding UI change in a separate task. |
Done: openedx/openedx-learning#107 |
Thanks @pomegranited, I added it on 5af8d66 |
src/taxonomy/api/hooks/selectors.js
Outdated
|
||
export const callExportTaxonomy = (pk, format) => ( | ||
exportTaxonomy(pk, format) | ||
); |
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 don't think selectors is the correct place for this, although I think this might be a preexisting problem with this module.
I think it's important to keep this ADR in mind: https://github.com/openedx/frontend-template-application/blob/master/docs/decisions/0002-feature-based-application-organization.rst
None of the functions here are hooks or selectors in the commonly understood context of those terms.
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.
@xitij2000 I updated the UI components to match with the ADR here: b09b86a
About the data layer, we have try to use useQuery to get data. On df8432d I tried to match with the structure on the ADR, @xitij2000 could you check 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.
Given that this is using useQuery instead of redux I'm not sure how things would map. However, I think it's best to avoid confusion with exist terms like hooks, thunks, selectors, if you are not using those since someone else working on this might have difficulty navigating this codebase in that case.
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.
Thanks! I understand. I deleted thunks.js
and I move hooks.jsx
to api/apiHooks.jsx
(to avoid use hooks or any other exist term). Also I added a docstring in api/apiHooks.jsx
to explain all of this.
const orgsCountEnabled = () => orgsCount !== undefined && orgsCount !== 0; | ||
|
||
const onClickMenuItem = (menuName) => { | ||
switch (menuName) { |
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.
If there is only one option, wouldn't this be clearer as a simple if condition?
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.
In future tasks more menu items will be added. I have added a comment for 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.
Sure, that makes sense. Would it be cleaner in this case to have a dict based approach?
i.e. something like this:
const menuItemActions = {
'export': setIsExportModalOpen,
'import': setIsImportModalOpen,
...
}
menuItemActions[menuName]?.(true)
This might end up being less clear depending on the usage though since I don't know the whole context.
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.
Thanks for the suggestion. I like it. I added it on this commit: 080b03e
@ChrisChV Is this ready for another look from @xitij2000 ? Or are you still working on refactoring the tests? |
@bradenmacdonald Yes, I will check this way. @xitij2000 do you have any comments about the changes here? or recommendations? So I can do changes in one batch :) |
@xitij2000 I updated the tests. It's full ready for another review |
src/taxonomy/data/thunks.js
Outdated
/* istanbul ignore next */ | ||
const exportTaxonomy = (pk, format) => ( | ||
getTaxonomyExportFile(pk, format) | ||
); |
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.
@ChrisChV IIRR, thunk.js
is for redux operations (ref). And since exportTaxonomy
is just wrapping an API function, can't we just call getTaxonomyExportFile
directly where it's needed?
Is that right @xitij2000 ?
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, thunks are where you can connect the API to the redux store. Since this is using a different approach with useQuery, I think there might not be any thunks here.
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.
Thanks! Ok, I agree. I deleted thunks.js
080b03e
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 currently not able to test this in running since my devstack is set up for something else I don't want to delay this.
Has it been manually tested?
const orgsCountEnabled = () => orgsCount !== undefined && orgsCount !== 0; | ||
|
||
const onClickMenuItem = (menuName) => { | ||
switch (menuName) { |
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.
Sure, that makes sense. Would it be cleaner in this case to have a dict based approach?
i.e. something like this:
const menuItemActions = {
'export': setIsExportModalOpen,
'import': setIsImportModalOpen,
...
}
menuItemActions[menuName]?.(true)
This might end up being less clear depending on the usage though since I don't know the whole context.
src/taxonomy/data/thunks.js
Outdated
/* istanbul ignore next */ | ||
const exportTaxonomy = (pk, format) => ( | ||
getTaxonomyExportFile(pk, format) | ||
); |
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, thunks are where you can connect the API to the redux store. Since this is using a different approach with useQuery, I think there might not be any thunks here.
src/taxonomy/api/hooks/selectors.js
Outdated
|
||
export const callExportTaxonomy = (pk, format) => ( | ||
exportTaxonomy(pk, format) | ||
); |
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.
Given that this is using useQuery instead of redux I'm not sure how things would map. However, I think it's best to avoid confusion with exist terms like hooks, thunks, selectors, if you are not using those since someone else working on this might have difficulty navigating this codebase in that case.
Hi @xitij2000 ! Yes! |
@xitij2000 I addressed your comments. It's ready for another review |
|
||
* ``edx-platform`` Waffle flags: | ||
|
||
* ``contentstore.new_studio_mfe.use_tagging_taxonomy_list_page``: this feature flag must be enabled. |
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.
nit:
* ``contentstore.new_studio_mfe.use_tagging_taxonomy_list_page``: this feature flag must be enabled. | |
* ``new_studio_mfe.use_tagging_taxonomy_list_page``: this feature flag must be enabled. |
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.
This is correct, but all the other feature flags use contentstore.new_studio_mfe...
so that was a small mistake on our part. Doesn't really matter though.
Hi @xitij2000, kindly reminder to do another round of review here. We need to unblock and merge this. I suggest that if there is another recommendation on the architecture and structure of the |
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.
Looks good! Just one small nit.
@bradenmacdonald @xitij2000 It's ready to merge. I don't have permission to do it |
@ChrisChV 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
* feat: System-defined tooltip added * feat: Taxonomy card menu added. Export menu item added * feat: Modal for export taxonomy * feat: Connect with export API * test: Tests for API and selectors * feat: Use windows.location.href to call the export endpoint * test: ExportModal.test added * style: Delete unnecessary code * docs: README updated with taxonomy feature * style: TaxonomyCard updated to a better code style * style: injectIntl replaced by useIntl on taxonomy pages and components * refactor: Move and rename taxonomy UI components to match 0002 ADR * refactor: Move api to data to match with 0002 ADR * test: Refactor ExportModal tests * chore: Fix validations * chore: Lint * refactor: Moving hooks to apiHooks * style: Nit on return null --------- Co-authored-by: Rômulo Penido <[email protected]> Co-authored-by: Christofer Chavez <[email protected]>
Changes added:
Screenshots
Testing instructions
Export
.Export
on the Export modal with CSV format.Export
on the Export modal with JSON format.Other info