-
Notifications
You must be signed in to change notification settings - Fork 1
Conversation
c45c93c
to
54eb4c3
Compare
54eb4c3
to
28f4a3d
Compare
Codecov Report
@@ Coverage Diff @@
## develop #106 +/- ##
===========================================
+ Coverage 97.82% 98.11% +0.28%
===========================================
Files 103 103
Lines 3685 4241 +556
===========================================
+ Hits 3605 4161 +556
Misses 80 80
Continue to review full report at Codecov.
|
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 switched to this branch, ran npm install
, and was able to view and run the code. It's very satisfying to see the search results changing as I select names.
Sometimes clicking the checkbox seems not to register? Either that, or it requires that I am very precise and click only in the box. Can we make the labels clickable also?
As we discussed, when I click on book detail and then go back, I get a page with no styles in Chrome - I figured out this my fault, we need a Vary
header. I'll add that shortly.
I think there might be a case where the load doesn't happen properly - when I go back from the page detail or when I reload a page with options set, the search filters aren't getting populated.
I added some comments the code, but the biggest thing I'd like to see is more comments describing the different components and how they relate.
@@ -0,0 +1,25 @@ | |||
export default Vue.component ('FilterChoice', { |
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.
Should components have a doc string or comment? It seems like it would be helpful to orient in terms of context and use case or goals for a component.
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 like this idea; makes sense to document them at that level. I'll add a docstring-like comment at the top of the files.
@@ -0,0 +1,25 @@ | |||
export default Vue.component ('FilterChoice', { | |||
template: ` | |||
<label :active="active" is="sui-button" role="checkbox" basic circular compact> |
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.
Missing class="..."
here for basic circular compact?
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.
so the is="sui-button"
tells Vue that I'm using a different tag (label
) when I actually want to render a button (sui-button
), which would receive the basic circular compact
boolean attributes at the end of the tag as props to sui-button
, which ultimately renders:
<label class="ui button basic circular compact"></label>
this is coming from semantic-ui-vue. we can talk more about the library - it seems like it might not be well-maintained, but I'm not sure if there is an alternative to make the semantic UI behaviors play well with Vue.
:name="name" | ||
v-model="active" | ||
hidden | ||
> |
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 prefer closed tags. Not sure if it actually matters here (I know it does for django templates if we want to use the assertContains
with html)
`, | ||
props: { | ||
name: String, | ||
label: String, |
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 label and value are different to allow for displaying facet counts? Maybe warrants a comment?
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.
"label" is the user-friendly display name; "value" is the value
attribute that gets used on the <input>
element. I think if I document the components' props with a docstring like you mentioned this will be clearer.
template: ` | ||
<div class="range-facet"> | ||
<div class="inputs"> | ||
<sui-input :placeholder="minVal" /> |
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 looks like sui-input
is a semantic-ui vue element. I wonder if the approach & combination of tools needs to be written up briefly somewhere? Not sure where yet. Why sui-input
here but not in FilterChoice
?
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.
FilterChoice
actually isn't used currently since filters aren't implemented. I went back and forth between having a component to represent a single choice/checkbox (essentially a custom wrapper around <input>
) vs just using <sui-input>
...most of that struggle was prior/during/the cause of me implementing Vuex, because having the checkbox maintain its own state and simultaneously publish that state to the form wasn't working well.
The reason using semantic-ui vue is necessary at all is because the behaviors that semantic UI provides (like the js used for the interactivity on the site search bar and mobile menu) might not play well if used inside a Vue component.
@@ -0,0 +1,31 @@ | |||
import FilterChoice from './FilterChoice' |
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.
Comments or docstrings would be really helpful to help understand the difference between SearchFilter
and SearchFacet
]), | ||
options() { | ||
return [ | ||
{ |
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.
Will this be pulled from / generated via the django form in future so we don't have to duplicate options?
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.
Yep, that's my hope. Should be able to just pass it into the component using html.
</search-facet> | ||
</div> | ||
</sui-segment> | ||
<sui-segment inverted class="active-items"> |
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.
Should only display when there are active items, right?
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.
Do we have a design of the form with no options active? The spec for the Annotations search shows one without this section displayed...should it just go away completely when nothing is active?
['annotator'] | ||
], | ||
activeTab: 0, | ||
facetConfig: [ |
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.
These would also be great to configure from the Django form somehow (I know we discussed that at some point)
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.
Yeah, hoping to use the same approach here.
]), | ||
}, | ||
created() { | ||
this.setEndpoint('facets/') |
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.
Can we make this configurable too? I'm imagining a few options being set in the template - not sure what makes the most sense. But we should set this via Django URL rather than hard-coding it 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.
Yep, another thing we can pass in using html.
…op-django into feature/search-form
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 really slick. I had a few comments, one based on one getter that I'm a bit confused about but otherwise it's great to use.
I do note that if I toggle off the range selector tab I lose the year I picked, but I also gather that may be WIP.
return { | ||
filter: '', | ||
alphaFilter: '', | ||
alphabet: String.fromCharCode(...Array(91).keys()).slice(65) |
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.
Maybe this would be good to extrapolate away as a Vuex getter that takes an alphabetical facet's results and returns an alphabet with letters not present marked (or vice-versa)?
}, | ||
methods: { | ||
...mapActions([ | ||
'setRangeFacet', |
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 am probably missing something here, but I see getters for setRangeFacetMin
and setRangeFacetMax
but not setRangeFacet
.
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.
Yeah, these are placeholders - I started out using a similar approach to the normal facets (one set
function) but realized I needed two and haven't changed it yet. Coming soon...
5d1bd90
to
6219d8a
Compare
I have some comments, but I'm not sure any of them merit holding up this PR any further. I expected to see a one or two line comment at the beginning of each component saying what it is / what it is used for. The method and property level documentation is much improved, but the higher level documentation would be good to add at some point. The checkboxes are still difficult to click and clicking on the label doesn't toggle. Publication range input doesn't have validation - not constrained to the min/max, doesn't require second date to be larger than the first. It also submits the form with a partially typed date if you are slow or thinking about what date you want - hopefully the same validation can address that. An active publication date filter doesn't display on the list of selected filters, so if you're not on that tab it's not obvious the filter is in effect or easy to clear. When I experimented with the publication dates, I also discovered a bug on the django side (my code) - 500 error when you try to load an empty result set, which is easy to do if you send nonsensical dates. I know what I need to fix. |
Couple more observations as I play with it more:
|
refs #103 and #102
todos:
implement passing in component config from django templatetracked on Refactor search components to allow passing props & html in #109add "clear facet" buttontracked on As a user, I want to clear all selections from a particular search facet so I can change parts of my search without losing the whole search. #110 ; moved to "nice to have"