Skip to content

Conversation

@AlexJacksonDS
Copy link
Contributor

Added no javascript filtering of admin users in a (hopefully) fairly generic way that can be reused for other filtering. Some of the data structures are a bit weird here in a similar way to ones for the generic sorting.

The layout gets a bit odd at very small mobile layouts due to the size of the buttons, but it's probably OK. Checked that the screen reader reads it OK

image

image

Copy link
Contributor

@DanBloxham-sw DanBloxham-sw left a comment

Choose a reason for hiding this comment

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

A few comments to look at.

I'm also not seeing anything to indicate the filters are applied to a cookie - is that requirement being avoided or added in another subtask?

@AlexJacksonDS
Copy link
Contributor Author

I'm also not seeing anything to indicate the filters are applied to a cookie - is that requirement being avoided or added in another subtask?

I've created a separate subtask for this now. No idea how possible it will be anyway. Something to figure out once we have a working filter setup.

Copy link
Contributor

@DanBloxham-sw DanBloxham-sw left a comment

Choose a reason for hiding this comment

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

Looks good to me. Couple of comments I've left as unresolved as they are still open for discussion and can act as reminders for other tasks.

@stellake
Copy link
Contributor

stellake commented Jul 1, 2021

The mobile version does look a bit crowded.. Maybe worth trying to move the "Clear filters" button below the filter tags:
image

I also wonder if it's worth adding "Filters"/"Applied filters" text before the list of filters for extra clarity (especially useful in mobile view I think)

Having said that I'm actually surprised how good the desktop version looks! 👍

@AlexJacksonDS
Copy link
Contributor Author

Desktop - added the labels and tidied up the spacing on the buttons so the text is vertically centred
image

Mobile - Clear filters button now collapses below the applied filters tags. Fixed the issue where the buttons fell onto the next row when the input was selected. (This was a problem with the search box on the live site too)
image

Also did some general css refactoring for the searchable elements classes. Removing some unused ones and pulling in some common settings. Hopefully 416 won't cause me a major merge headache.

Copy link
Contributor

@stellake stellake left a comment

Choose a reason for hiding this comment

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

Quick question - have we documented this anywhere so far?

Comment on lines +77 to +80
<input type="hidden" id="searchString" value="@Model.SearchString" />
<input type="hidden" id="filter-by" name="filterBy" value="@Model.FilterString" />
<input type="hidden" id="select-sort-by" value="Name" />
<input type="hidden" id="select-sort-direction" value="Ascending" />
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you think we could use the asp-route-{value} as an alternative to all the hidden inputs in the markup?
https://docs.microsoft.com/en-us/aspnet/core/mvc/views/working-with-forms?view=aspnetcore-3.1#the-form-action-tag-helper


public string FilterName { get; set; }

public IEnumerable<(string DisplayText, string Filter)> FilterOptions { get; set; }
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe worth renaming the "Filter" to "Id" as a property "Filter" on "FilterOption" can get confusing

{
// Given
var inputItems = QueryableHelper.GetListOfSortableItems("a", 1, "a", 3, "b", 2);
var expectedItems = new[] { new SortableItem("a", 1), new SortableItem("a", 3) }.AsQueryable();
Copy link
Contributor

Choose a reason for hiding this comment

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

Given that we declare the sortableItems anyway, could we do something like (instead of using the helper):

var inputItems = new[] { item1, item2, item3 }
var expectedItems = new[] { item1, item2 }
...

Copy link
Contributor

Choose a reason for hiding this comment

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

Would it also be worth refactoring
var item1 = new SortableItem("a", 1) (or even itemA1, itemA2, itemB1)
etc
so we don't need to declare these in lots of different places?

  • can do similarly in queryable extensions test


public string DisplayText { get; set; }

public string Filter { get; set; }
Copy link
Contributor

Choose a reason for hiding this comment

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

I still think Filter could have a DisplayName, just like FilterOption. I wonder if "FilterId" or "FilterValue" would be more intuitive as a name 🤔

@@ -0,0 +1,17 @@
namespace DigitalLearningSolutions.Web.ViewModels.Common
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we want to put all the search/sort/filter common classes under a new folder (maybe SearchSortFilter) as the Common folder is having quite a lot of classes now.

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 wonder if it would also be worth putting the ViewComponent models into a folder at some point too

using DigitalLearningSolutions.Web.ViewModels.Common;
using Microsoft.AspNetCore.Mvc;

public class FilterableTagsViewComponent : ViewComponent
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this be a partial instead if all we need is rendering a view with the model?


private static bool FilterOptionsContainsFilter(
string currentFilter,
IEnumerable<FilterOptionViewModel> filter
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this also be filterOptions? And should the "filterValue" be "filterOption"?

Default,
Warning,
Success,
Other //This will result in the default blue nhsuk-tag
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason we support "Other" at this stage?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

"Having spoken to Carolyn and David, they agree that the first option ([blue,] grey, red, green) would be preferred. Thanks both."

Figured I might as well stick it in, but the name is probably bad

Copy link
Contributor

Choose a reason for hiding this comment

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

I thought that [blue] meant the colour of the listed filters, but I will clarify this with Kevin tomorrow morning.. Shouldn't block this though

Copy link
Contributor

Choose a reason for hiding this comment

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

Kevin confirmed that the blue NHS tag can go and we can use blue for applied filters

{
// Given
var inputItems = QueryableHelper.GetListOfSortableItems("a", 1, "a", 3, "b", 2);
var expectedItems = new[] { new SortableItem("a", 1), new SortableItem("a", 3) }.AsQueryable();
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it also be worth refactoring
var item1 = new SortableItem("a", 1) (or even itemA1, itemA2, itemB1)
etc
so we don't need to declare these in lots of different places?

  • can do similarly in queryable extensions test

Copy link
Contributor

@stellake stellake left a comment

Choose a reason for hiding this comment

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

Looks good - added a comment about the TagStatus blue not being required, but no need for re-review 👍

@AlexJacksonDS AlexJacksonDS merged commit 2732d97 into master Jul 7, 2021
@AlexJacksonDS AlexJacksonDS deleted the HEEDLS-532-admins-no-js-filtering branch July 7, 2021 09:24
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.

3 participants