tuckerchapin / keebhunter Goto Github PK

Beyond the /search page there's not much in the way of loading and when the backend gets choked there's fair amount of pop-in and FOUC.

• Better un-loaded state/styles for <TagList> before the tags are retrieved
• Any sort of loading communication on <ProductPage>
• Better UI blocking and activity communication when saving a new entry or edits

Sadly, this is likely a wontfix. For the time being iOS and desktop Safari do not support the flex gap property and so the <TagInput> component renders without spacing between the tags. It doesn't look good, but it doesn't affect the functionality. The latest Safari technical previews support gap so whenever that makes it into a full release, iOS support will likely be soon to follow. If someone wants to make a shim for this they are more than welcome to, but even as an iPhone user myself I can't find the drive to do so.

Currently, all of the tags are fetched at once at the start and all of them are displayed to the user in the <TagList> sidebar. With >100 Tags the workaround at the moment is to .limit(200) on this request. That's not great, but showing all 100+ tags isn't great in the first place.

The solution is to add a cloud job that will populate a popularity field for tags. Something roughly like

Tag.popularity = Query(Products).contains('tags', Tag).count()

The <TagList> will then only show the top 5 or so tags by popularity for each category. Possibly with an option for the user to click "show more" and load the next few in that category. This should cut down on visual clutter.

Then each <ProductResult> and <TagInput> will need to fetch and include their tags. Any tags shown on a product page, or entered in as a filter, or otherwise marked as selected should also be included in the tag list. This will require a bit of a rework to the <TagList> component and the store.

Currently, images are compressed before being saved and, on saving, the first image is used as a thumbnail and resized. The utils.thumbnailify and utils.compress functions should likely be moved server-side as their own functions or Parse.File.beforeSave triggers.