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

Issue #309 - Browse Page #375

Merged
merged 26 commits into from
Dec 3, 2018

Conversation

storrisi
Copy link
Contributor

Fixes #309

Initial WIP PR with some refactoring of the AbstractPageDefinitions / PageDefinitions, in order to clean the code, remove unused method, move shared methods into utils classes or HoC.

Most of the methods should be used by the new PageBrowse , so the refactor it's necessary to avoid code duplication.

Copy link
Member

@jeffmcaffer jeffmcaffer left a comment

Choose a reason for hiding this comment

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

Overall a great direction. I've left some comments in the code. Some general things here.

  • Need to distinguish strategies for libaries/utils, hierarchies, components, and HOCs. Some things here I would have expected to be one are another (see file comments). I generally prefer composition over class hierarchy but certainly room for both.
  • With the intro of Browse we now have user-managed and system-managed lists. Definitions is a list created and managed by the user. It should have share, DnD, ... Browse OTOH is filtered and sorted by they user but list itself is driven by the system. (likely does not have share, DnD, ...). It would be interesting to think of the user behaviors in each of these contextx.

}

function mapDispatchToProps(dispatch) {
return bindActionCreators(
Copy link
Member

Choose a reason for hiding this comment

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

As a general formatting comment please go wide rather than tall. Here all on one line please. Similar comment throughout the 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.

That's a Prettier default behaviour, i will check if we can avoid it

Copy link
Member

Choose a reason for hiding this comment

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

If you just don;t put any line breaks in then Prettier will format it like this

function mapDispatchToProps(dispatch) {
  return bindActionCreators({ uiNavigation }, dispatch)
}

@@ -0,0 +1,36 @@
import React from 'react'
Copy link
Member

Choose a reason for hiding this comment

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

copyright/license header

@@ -224,8 +148,49 @@ export class PageDefinitions extends AbstractPageDefinitions {
)
}

updateList(o) {
return uiBrowseUpdateList(o)
renderFilter(list, title, id) {
Copy link
Member

Choose a reason for hiding this comment

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

feels like this should be factored out as well like SortList

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 agree, i've moved only some blocks of code for now, this should become a separate component

const { sequence, showFullDetail, path, currentComponent, currentDefinition } = this.state
return (
<Grid className="main-container">
<ContributePrompt
Copy link
Member

Choose a reason for hiding this comment

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

probably should put all the popups at the top or bottom. I like having explicit render methods for them. Nice

})
}

doSave() {
Copy link
Member

Choose a reason for hiding this comment

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

will be interesting to see how widely usable the share functions will be. Browse likely should not allow sharing (at least not until we do mulitselect) as the list in Browse is "infinite".

dispatch(uiBrowseUpdateList({ add: component }))
}

dropZone(child) {
Copy link
Member

Choose a reason for hiding this comment

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

Can this be part of a Drop component? along with onDrop above?

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, for sure

* Abstract methods for Dropping functionality
*
*/
export default class Drop {
Copy link
Member

Choose a reason for hiding this comment

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

Should this be a Component? Where else would we use this function?

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 was starting building a utils class thinking of reusing all the related methods, but your comment pointed me out in the right direction.
We don't need a class of methods for the Drop functionality, but it should be a real Component, plugged in like the DropZone library

}
}

onAddComponent(value) {
Copy link
Member

Choose a reason for hiding this comment

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

this will not be generally usable. Only the definitions list view (and harvest) are lists that are user managed.

return { coordinates }
}

loadFromListSpec(list) {
Copy link
Member

Choose a reason for hiding this comment

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

this (and related methods above) are only relevant to user-managed lists (definitions and harvest).

@storrisi
Copy link
Contributor Author

Thanks @jeffmcaffer , the difference between user-managed and system-managed is interesting.
I will work in order to distinguish the two behaviour, probably creating some HoC or Abstract Components that contains the logic.
What do you think?

@jeffmcaffer
Copy link
Member

User vs system may be useful. I was just observing the difference as I read through your changes. Not sure if that is the major pivot or just a characteristic. From a code point of view if we use composition more then we don't have to think too hard about that as a hierarchy as things are a bit more mix and match.

From a user experience point of view it may be useful to essentially capture user expectations (e.g., as a user I am constructing/managing a list vs observing an existing list).

Copy link
Member

@jeffmcaffer jeffmcaffer left a comment

Choose a reason for hiding this comment

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

First pass of comments. Generally I like the direction but but am unsure of some of the finer points of how/why bits are being factored out and where they are being put.

import { ROUTE_BROWSE } from '../../../../utils/routingConstants'
import UserManagedList from '../../../UserManagedList'

class PageBrowse extends UserManagedList {
Copy link
Member

Choose a reason for hiding this comment

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

Browse should be a System managed list. The list is generated by the system. all the user can do is sort/filter. They can't actually add or remove things from the list nor should they be able to share or save. (perhaps they can share/save but that would just be their sort/filtering settings)

}

render() {
const { components, definitions } = this.props
Copy link
Member

Choose a reason for hiding this comment

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

Seems like this used to be shared. Did we lose some shared code that used to be in AbstractPageDefinitions

import ButtonWithTooltip from '../../Ui/ButtonWithTooltip'
import ShareButton from '../../Ui/ShareButton'

export default class ButtonsBar extends Component {
Copy link
Member

Choose a reason for hiding this comment

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

similar comment to previous. is this reusable or specific to PageDefintions?

import ButtonWithTooltip from '../Ui/ButtonWithTooltip'
import ShareButton from '../Ui/ShareButton'

export default class ButtonsBar extends Component {
Copy link
Member

Choose a reason for hiding this comment

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

duplicate with the other ButtonsBar above?

@@ -0,0 +1,55 @@
import React, { Component } from 'react'
Copy link
Member

Choose a reason for hiding this comment

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

wrt folder naming, how are you deciding what is "navigation"? There are some places where there is a "ui" segment in the path? This is all UI so that designation is unclear. Here what is the significance of "sections"?

More generally it feels like we are making a complex and deep folder structure where in reality we just have a bunch of components that get assembled in different ways to form the UI. There are a few clear things that go together but otherwise, most things should be generic and stand-alone.

shareGist: PropTypes.func
}

onSelect = type => {
Copy link
Member

Choose a reason for hiding this comment

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

Can this be part of ShareButton?

import { DropdownButton, MenuItem } from 'react-bootstrap'
import PropTypes from 'prop-types'

class SortList extends Component {
Copy link
Member

Choose a reason for hiding this comment

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

SortButton?

import FilterBar from '../../Sections/FilterBar'
import FullDetailPage from '../../../FullDetailView/FullDetailPage'

class PageContribution extends UserManagedList {
Copy link
Member

Choose a reason for hiding this comment

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

Actually I wonder if this should be SystemManaged? If it is the list of definitions in a curation, that is not something that the user can manage (given the PR is already opened). In the future you could imagine that we'll allow uses to "edit" the curation but there are a number of workflow issues with that so ti will be a while.

</Button>
&nbsp;
<Button bsStyle="success" disabled={hasChanges} onClick={doSave}>
Save
Copy link
Member

Choose a reason for hiding this comment

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

what does "save" do? We have "share" but not sure about save.

@storrisi storrisi changed the title WIP : Issue #309 - Browse Page Issue #309 - Browse Page Nov 30, 2018
@storrisi
Copy link
Contributor Author

@jeffmcaffer i've finalized the work here.
This is how the page looks like:
schermata 2018-11-30 alle 16 02 40

As you can see this page is quite a "mix" of a System Managed list , which is basically Read-Only, and a User Managed List.
This kind of page has all the System Managed List functionalities, but allow the user to edit the definitions and make a curation.
Beside that, the user can't modify the returned list, neither share it.

Two small advice:

  • When a user selects a provider, the application calls a "/browse?pattern={provider}" API, which is not already implemented
  • given that, i've hidden the "Browse" voice from the Navigation Menu.
    You can decide to wait to merge this PR until we have completed the service implementation, or merge it anyway and keep the page hidden.

Copy link
Member

@jeffmcaffer jeffmcaffer left a comment

Choose a reason for hiding this comment

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

Just about there. Some more minor comments added.

Note, looking through the commits, there is f02ec18 which seems to remove EntitySpec.fromString() but that change is not showing up in the overall PR. I do not think we should remove that. It should, perhaps call fromPath. that would be a good mirroring of the toPath and toString functionality.

src/actions/definitionActions.js Outdated Show resolved Hide resolved
src/actions/definitionActions.js Outdated Show resolved Hide resolved
src/actions/definitionActions.js Outdated Show resolved Hide resolved
src/components/FullDetailView/FullDetailPage.js Outdated Show resolved Hide resolved
src/components/UserManagedList.js Outdated Show resolved Hide resolved
src/components/UserManagedList.js Outdated Show resolved Hide resolved
src/components/UserManagedList.js Outdated Show resolved Hide resolved
src/utils/utils.js Outdated Show resolved Hide resolved
@@ -52,17 +52,11 @@ const initialStateNavigation = [
isSelected: false
},
/*{
Copy link
Member

Choose a reason for hiding this comment

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

hmmm, not sure. there are some "hidden" routes that we use for deep linking to both the full details PAGE and the page that shows all of a particular PR. Not sure which if any of these is "inspect".

Also, will you need to uncomment this to have Browse show up in the UI?

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, this is a temporary workaround if you want to merge this PR and don't allow anyone digging into this page while there isn't any related API available.

@storrisi
Copy link
Contributor Author

storrisi commented Dec 3, 2018

I've updated the PR based on your suggestions and also changed the name of the api call method in order to be more generic.

@jeffmcaffer jeffmcaffer merged commit 2116a32 into clearlydefined:master Dec 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants