joealden / listed Goto Github PK

Read title ^

Now that StrictMode has been enabled for the site, the following warning is logged to the console:

Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of StyledComponent which is inside StrictMode. Instead, add a ref directly to the element you want to reference.

This is because as mentioned in styled-components/styled-components#2154 (comment), there is no other suitable alternative to the findDOMNode method currently in React for styled-components' use case. The React team have said that they are thinking about implementing a solution for this unhandled use case (facebook/react#13841 (comment)).

For now, nothing can be done, as styled-components is waiting on React to implement a solution. This issue is here as a reference to explain why this error is logged to the console in dev mode.

Little bits of the accent colour can be seen at the bottom left and bottom right of the screen. This is likely due to some default styling where the buttons have a border-radius: 1px or something similar. Try and set border-radius: 0 on the button and see if that fixes it.

There is a bug on mobile Firefox where the back to top button shows when it shouldn't.

Steps to reproduce:

• Open up listed on Firefox mobile (Android)
• Scroll to the Post titled "Checkout" and click on it
• Select all of the tags to add them to the filter
• Press back

Now the list should only be a few items long, and be scrolled to the top of the page, but the back to top button still shows. This is likely due to a bug in Firefox where the scroll event isn't being triggered when the scrolling is not done by the user, as in this case it is done because the list is shortened, causing the page to only be the size of the viewport.

When the user clicks on the 'About' button in the header, do the following:

• Change the 'About' button to say 'Close' and attach an onClick event to handle that.
• Fade in the background of the about panel container above the section where preview images are shown in the list.
• At the same time, add an overlay to the main section of the site like when the Info or Filter sections are opened. When this overlay is clicked, it needs to perform the same action as when the close button is pressed.
• Fade in the content in the about panel.

When the user clicks close, do the same but in reverse.

Invision link: https://projects.invisionapp.com/d/main#/console/15720155/331172992/preview

Note the following about the design:

• For now, the theme switching button should stay, unlike what is shown in the design.
• The baseline of the first line of text in the about panel is aligned with the baseline of the first list item when the list is at its starting position.
• 'Follow our Instagram' needs to link off to an Instagram page (this needs to be created).
• The 'Joe Sutton' and 'Joe Alden' text need to link off to portfolio sites.

Like on desktop, should the mobile filter have a "Clear all" button so the user can quickly get rid of all currently selected tags?

If so, where should it go? Placing it like it is on desktop (on the bottom right of the selected tags list) doesn't look the best, as it breaks up the single column layout.

When in the tag search screen on mobile chrome (Android only for some reason) or mobile Safari, the list of tags extends to behind the "Back to Filter" button, meaning that the tags at the bottom of the list are cut off, and are inaccessible to the user.

This means that this screen's layout needs to be reworked. It is currently using the vh unit in the height calculation for the list (height: calc(100vh - Xpx) where X is the height of the input box and the "Back to Filter" button combined). As mentioned in other issues, the vh measurement isn't consistent across browsers.

A possible solution to this is to redo the layout using flexbox, where the input box and list is wrapped in a flex container, and then the list is set to flex: 1 so that it fills in the space left over in the container. This would require setting a fixed height for the flex container (height: calc(100% - 60px) as the button is 60px high).

The dropdown menu on mobile should be closed if the user visits any of the following screens:

• Filter
• Info
• About

This is so that when the user returns to the main screen, the dropdown menu isn't still in its open state. In the sites current state, it feels a bit wrong that the dropdown remains open between screens.

Due to there being a 0.3s long transition on all of the listed screens opening, the dropdown menu will likely have to be closed after the animation has finished. Otherwise it may look a bit weird, as you will see the dropdown menu closing during the transition to the other screens.

On both desktop and mobile, scrolling should not be allowed when any of the following sections are open:

• Filter
• Info
• About

Currently on desktop, there is an event handler that prevents the user from scrolling with their mouse wheel, however, they can still scroll down the list if they use the arrow buttons or scroll using the actual scroll bar. Both of these alternate ways of scrolling also needs to be disallowed. Note that on desktop, the scroll bar area needs to remain so that on OS' that are not macOS, the page doesn't jump.

On mobile, there is currently no scrolling prevention. Scrolling prevention is needed as currently if the user scrolls for whatever reason on any of the sections, it will scroll the main list down. This is not what should happen because it means that the user will lose their position in the list when it should be in the same spot as before the section was opened.

Idea

Instead of using a load of CSS media queries and React media queries (likely using the react-media library), somewhere near the root of the component tree (probably just below the theme provider as both mobile and desktop will use it), a single React media query is used. This media query (still probably using react-media unless React Hooks are stable by the time this is implemented) will render the <Desktop /> component if the viewport width is >= 1024px, or it will render the <Mobile /> component if the viewport is < 1024px. This media query will be wrapped in a <React.Suspense /> component so that both the <Desktop /> and <Mobile /> components can be imported using React.lazy.

Inspiration: https://twitter.com/necolas/status/1058949410128707584

Benefits

Separating the desktop and mobile designs into their own lazy loaded component trees has the following benefits:

• The amount of code the user downloads will be reduced if they only render one of the two component trees (which will be the most common case). For example, if the user loads the page on desktop and doesn't resize the browser to a mobile size, they will only download the code required for the desktop version of the site.
• As styled-components is used for component level CSS, the user will also only download the CSS they need for the current breakpoint. Without this code-splitting mechanism in place, the user would download all media query data even when it likely won't be used.
• Components that are designed and built just for desktop or just for mobile will be a lot simpler to write and read. For example, a component that is only rendered on the desktop does not need to have loads of conditionals and CSS media queries, unlike a generic component that would be rendered both on desktop and on mobile.
• Code that can be shared across desktop and mobile can still be shared through JavaScript modules (This includes JavaScript [regular functions], HTML [components] and CSS [styled components]).

Potential Issues

• As mentioned here in the React docs, React.lazy and Suspense are not yet available for server-side rendering. As Gatsby statically server-side renders the site at build time, this may be an issue. I'll have to play around with it in Gatsby and see what happens. As also mentioned in the react docs section linked above, react-loadable may have to be used as they do support server-side rendering.
• If React.lazy and Suspense are used, then I need to check how 'fetch on render' lazy loading actually works. From what I can tell, the proposed way of wrapping the media query in a Suspense component should work, but I need to make sure that only the needed component tree is fetched instead of both of them.

Issue

@types/styled-components is currently pinned at version 4.0.3. At the time of this issue being created, the latest version is 4.1.0. Unfortunately, this version results in type errors in styled-components.ts as described here. As mentioned here, this type issue will (hopefully) be resolved in the next release of this package.

Resolution

When @types/styled-components releases a version that is greater than 4.1.0, try updating this package and see if the type errors still occur. If they don't, unpin this dependency and update it to the latest version.

When visiting the site on mobile Firefox, depending on how you press the buttons (if you click in the padding of the button), it brings up a "Select All" dialog that is basically impossible to dismiss. I have seen this behaviour before on the React docs mobile site as well.

A possible solution to this would be to disallow the selecting of the contents of these buttons using the user-select CSS property (https://developer.mozilla.org/en-US/docs/Web/CSS/user-select).

As shown in the following screenshot, when the viewport height is relatively small on desktop Firefox, the borders that separate the sections in the list don't extend down to the bottom of the page.

When looking further into it, the HTML tag seems to only extend down to the part that still has the borders:

The cause of this needs to be found and then this extra space needs to be removed. It is also worth noting that this doesn't happen in Chrome. I can also confirm that this happens in both Linux and Windows when using Firefox.

When a button is pressed on mobile Firefox, the button is left with an outline. As far as I know, the main reason for this outline is so that the user knows where their browser is currently focused on the page. This is useful for accessibility reasons on desktop (tabbing through the site with a keyboard). However, I don't see the need to have these outlines visible on mobile, as tab navigation on mobile isn't really a thing.

A possible solution to this is to disable the outline on all buttons in the mobile component tree.

It is also worth looking into something I remember seeing on twitter where the outline was preserved on keyboard navigation, but was hidden on pointer navigation. However, I seem to recall that the current browser support isn't very good.

Currently, CSS grid is being used to control the sites column sizing (60px for the header, 3fr for the main section, and 1fr for the image preview section [out of 100vw]). The same grid system is currently being used across 3 different components so that they all line up correctly (specifically Header.tsx, ListItem.tsx and Underlay.tsx). However, this means that components that wish to use this grid system that are above the components in the tree that use the grid, they either have to copy the grid layout and use empty elements to ensure that things align correctly, or they have to use a vw calculation that is not perfect. Currently, both the Info and About panels of the site are sized using the following CSS variables:

--logo-width: 60px;
--column-width: calc(calc(100vw - var(--logo-width)) / 4);

In theory, this calculation should result in the exact same size as 1fr as described above. However, in reality, this calculation is inconsistent with the grid version, and it is also different across browsers. This results in the sections that use the --column-width variable being slightly wider than the sections that use CSS grid. This can be seen currently when opening the about panel, as the border is off by a few pixels (this is different across browsers and OS' for some reason).

Another issue with the current system is that the grid rules are duplicated many times all across the component tree. This makes it had to maintain the grid, for example if I wanted to change the width of a column, I would first have to change all of the sections using their own grid, then I would also have to change the --column-width variable to account for this change.

A possible solution to this issue is to create a grid somewhere higher in the component tree and then let the children all use that one grid, however, I need to further research if it is possible to have deeply nested children use the parent grid.

Instead of changing the color of the category and tags, apply the same underline technique to the back button at the top of the info section. This will require the FilterButton.tsx component to be generalised so that it can have any text, and have any functionality when pressed (change the prop from being called openFilter to onClick).

Also potentially change the opacity of the category and tag text to show if they can be pressed or not.

Also, the "Back" button and the rest of the width of the screen to the right of it needs to be treated as a sticky header just like the main header. This is so that when scrolling occurs on mobile devices with smaller screens, the header with the back button and the underline is always in view.

Currently, after the reset functionality had to be removed from the logo click due to other concerns, there is no way to quickly reset all of the filter criteria on desktop.

Due to previous issues, this means that the reset button must live somewhere inside the filter drop down itself. The best place I can think of putting it is in the bottom left. This is because it wouldn't move any other content in the filter that already exists, and I don't think it will look too out of place. Placing it here is probably better than the original logo click as well because it will allow us to label it something like "Reset criteria".

1. Fix tag search list overflow on chrome mobile (change from using vh to calculate height, maybe use flexbox with flex: 1 for top section)

2. Change filter button in header underline to be the same as on desktop (so the line under it disappears from left to right when the filter is cleared)

3. Get rid of annoying "select all" (disable selection in CSS on some elements) and outlines on Firefox

4. The dropdown menu on mobile should be closed if the user visits any other screen (Filter, About or Info)

5. Fix the tag selection in the Info section. If the tag is already applied in the filter it should be the accent color, if it is not, it should just be the foreground color. When the user clicks on a tag that isn't already in the filter criteria, transition the tag from foreground color to accent color.

6. Get hamburger menu animation from @JoeSuttton and implement it

When opening the 'Info' or 'Filter' panel, the opacity transition on the main site overlay jumps to a darker color once the animation has finished. This happens in Firefox (and not in Chrome).

Todo:

• Check that it happens on machines other than mine (Solus)
• Check in other browsers that I do not have access to (Edge and Safari)

• Should we reset the scroll position of these lists when the filter is closed?
• Should we reset the tag search list scroll position when the user clicks the "Clear all" button?

On desktop, when an 'Info' button is pressed and the Info section opens, the main list needs to animate so that the post's title in the main list is baseline aligned with the title in the Info section.

This either needs to happen after the Info opening animation has done, or during it (most likely after it is done as it probably will look better and it will likely have better performance as both things aren't happening at the same time).

Add font-display: swap; to the font face declaration found in styles.css as shown here so that a flash of unstyled text happens instead of a flash of invisible text. This might require setting some fallback system fonts to use (most likely Arial in this case as it is widely available and is pretty similar to Suisse Intl).

Maybe have two lists where each time the filter is changed, the lists alternative in which ones are shown to the user.

May have to think about it will look if the user changes the filter criteria too fast (Before the fade in a out transitions have both occured).

https://reactjs.org/docs/optimizing-performance.html#virtualize-long-lists

• First, test the non-virtualised list with 100+ of items
• With this version, test the performance impact in the following ways:
  • Visually
  • React Profiler (as triggering list re-renders, like when sorting the list [depends on #2])
  • Chrome and Firefox performance tools (Like CPU and RAM usage)
• With this data collected and happy that performance optimisations are required, implement virtualisation of the list using react-window (or react-virtualized if the slimness of react-window doesn't cut the use case [having the list item height change when the viewport width changes, as well as the list adjusting height when the viewport height changes])
• Once implemented, analyse the same metrics as talked about above with the non-virtualised list as well as the following:
  • Check that the images still lazy loading correctly.
  • Check for any visible rendering issues when scrolling the list.

Currently, there is no quick way to clear the contents of the search box when searching for tags. This is especially true for the mobile tag search, as clicking of the tag search list does not automatically clear the current search.

Currently I do not have the designs for the about section on mobile (@JoeSuttton is working on it) so I cannot currently move forward with implementing this. Once the designs are done, create the about section and ensure that the user can visit it by clicking on the 'About' button in the dropdown menu. There will likely be some kind of transition to get to this page, so this also needs to be implemented. While the about section is open, disabling scrolling.

Currently on Chrome, the 'Back To results' button in the filter section gets cut off when the URL bar is visible on mobile. This is because of how Chrome treats where the bottom of the viewport is. Gatsby's site seems to get around this problem somehow (https://www.gatsbyjs.org/). Look into how they do this.

At the moment, if the selected tags list gets too long on desktop, it will just increase the size of the entire filter. This isn't how it should work. Instead, it show scroll if the list gets too long, just like the tag search list does, preventing the entire filter from growing.

The preview images shown in the site are all uploaded to Contentful at a resolution of 1130x640, and this is enforced by a validation rule in the CMS.

To help reduce the payload size of the images, I wanted to take advantage of gatsby-image's multiple image generation feature that uses the srcset attribute to tell the browser to load the correct image size depending on the size of the viewport. If the user is on tablet or mobile, they don't need the full resolution image as a lower resolution version would be indistinguishable from a higher resolution version.

However in the current version of the site, the site is only serving the full resolution version of the images to all devices no matter their screen size. I have a feeling that this is an issue to do with how I have configured the GraphQL page query. Read this part of the docs for more info on how the query should be structured, and also go to the /___graphql endpoint that is exposed by the Gatsby dev server for more info on what parameters the fluid property takes.

Here is a resource to use that has a two line hamburger menu that animates how we want ours to animate: https://heller.tv (note that you need to be at a mobile viewport size to see the hamburger menu)

So the animation should move the two lines to the middle, then rotates the lines opposite to each other to form a cross. This should all likely be done in 0.3s / 0.6s to match the time it takes for the menu to finish animating.

When looking at the source code of the linked site, they achieve the effect by have two divs as the two hamburger lines, and applying transform: translateY(-5px) to the first div and transform: translateY(5px) to the second div. This achieves the hamburger icon.

Then we the button is clicked, both divs have their transforms set to transform: translateY(0). With a transition applied, this brings the two lines together. Then once this has done, the first div has
transform: rotate(45deg) applied to it, and the second one has transform: rotate(-45deg) applied to it. This then creates the cross.

STUB

On both mobile and desktop, there are the 'Category' and 'Tags' sections in the Info panel. Within these sections, there is the category and the list of tags that the post belongs to. Currently, they don't do anything when pressed (they just call alert as a placeholder). The following should occur when they are pressed:

• If the post's category is pressed, the currently selected category needs to be changed to the category of that post. This is cause the main list to update with the new filter applied.
• If a tag is pressed, the tag should be added to the filter. This should only occur if the tag is not already applied as a filter.

Bottom of this site tooltip wanted:
http://www.instrument.com/work/sonos

As shown here, Safari doesn't currently support the Intersection Observer API. This API is used in gatsby-image to detect if the image should be fetched. Read more about this here.

As I don't use an Apple machine, I'll have to test this at a later date. This may not actually be an issue as Gatsby's babel config might polyfill the Intersection Observer API. I say this because it states here in the Gatsby docs that they automatically provide polyfills for browsers that have a relatively large user base (and the latest version of Safari is definitely one of them).

Currently, when the logo is clicked on desktop, it resets the filter criteria to the defaults. However, it does not reset the scroll position. It would make the most UX sense to have the user returned to the top of the list.

On Desktop, when the page reloads, the images show the alt text instead of the base64 version for some reason

https://reactjs.org/docs/strict-mode.html

1 - Firefox mobile bug where the back to top button shows when it shouldn't.

Steps to reproduce:

• Open up listed on Firefox mobile (Android)
• Scroll to the Post titled "Checkout" and click on it
• Select all of the tags to add them to the filter
• Press back

Now the list should only be a few items long, and scroll to the top of the page, but the back to top button still shows. This is likely due to a bug in Firefox where the scroll event isn't being triggered when the scrolling is not done by the user, as in this case it is done because the list is shortened, causing the page to only be the size of the viewport.

2 - Setup tsconfig.json and tasks.json or maybe tslint.json and vscode tslint plugin so that type errors are shown both in the console and in the file viewer. Possibly use another gatsby typescript plugin that allows for typechecking, unlike the standard typescript plugin offered by the gatsby team.

3 - Extract the "mobile priorities list" issue out into separate issues

4 - Change the "Implement filter section" issue or delete and create a new one. Most of the work has been done now on mobile, so the filter section issue should be refocused just to target the desktop implementation.

From the limited testing I have done on desktop Safari (as Safari only supports macOS), the site seems pretty broken.

These are some things that I noticed were issues:

• The lines that separate the info, title and preview sections are not visible
• The performance of changing post hover state is awful
• The performance of transitions isn't great
• Smooth scrolling doesn't work when the "back to top" button is pressed

STUB

Fix fade out looks bad when different category is selected or sort by changed (previously active item still in view when changed)

Make it so that when you click on the listed logo on either desktop or mobile, it resets the filter criteria to the defaults.

The about section currently works like this:

• The 'About' button in the header is pressed.
• The About section fades in over the image preview section.

This is how is should work eventually:

• The 'About' button in the header is pressed.
• Just the background of the About section (as well as the close button) fades in
• Once this fade in has finished, fade in the text in the About section.

This issue supersedes #1 as the About section has now been implemented, but the animations still remain to be done.

Currently, there is no transition between the logo showing and the back to top button showing on mobile. When the state change occurs, the currently shown SVG shown fade out, then once that fade out has finished, the other button is then faded in. The easiest way to implement this would likely be to use CSS animations and the delay property.

More Info

Source URL: https://dribbble.com/shots/4837241-uploading

1. Make tag search list on desktop close when clicking on the overlay. This includes clearing the input and settings the inputFocused state to false

2. Fix the scrolling, as I had to remove the handleWheel handler as it was stopping the tag search list from being scrollable

3. Add the tag and category color change from the mobile info section to the desktop info section

4. When changing any filter criteria, main list should be scrolled to the top

5. After the info section has been closed on mobile, the info section should he scrolled to the top. This is so that if the screen is small enough that the info section is scrollable, the next post to be opened will be at the top, instead of half way down.

6. Potentially the category and tags in the info section should be clickable to deselect after they have been selected

Invision links:

• https://projects.invisionapp.com/d/main#/console/15720155/328468703/preview
• https://projects.invisionapp.com/d/main#/console/15720155/327022596/preview

• History API: https://developer.mozilla.org/en-US/docs/Web/API/History_API
• Netlify Redirects: https://www.netlify.com/docs/redirects/

Make the tag search list on desktop close when clicking on the overlay. This includes clearing the input and setting the inputFocused state to false. This will likely mean that all of this state will need to be lifted up into src/components/desktop/Site.tsx so that both the Filter and Overlay components can update the state.

Two

1. Think about sharing state between component trees (as switching between viewport widths does not keep the state consistent). This would probably be best suited for context or useReducer when hooks are made stable.

2. Fix jolty image loading on the mobile info section (more noticeable on slow connections). Possible solution would be to somehow only load the base64 version of the image when scrolling the normal list so that it can be shown instead of nothing in the info section.

3. Think about how to make the back button on mobile (android) work like it feels like it should. Meaning that when on the info section, pressing the android back button should return you to the main list. It currently doesn't because the info section is treated as the same page (just an overlay).

Possible solutions:

• Use client side routing (reach-router most likely as it is baked into Gatsby) to push to history object. Downside is that the pushed URL wouldn't be refreshable or shareable, as it would only work clientside (or could it work server side as well?).
• Use a separate page in Gatsby's pages directory. This would fix the issues that the other solution has as you would be navigating to something like /info/${postId}. This solution would require a bit more plumbing that the previous solution as another GraphQL query would have to be created to fetch the data for the /info page. Also, it may be worth statically generating all of these pages through a custom Gatsby config. Also, this solution would bring up another issue. The issue would be that because the link is now sharable and a separate page, this link could be visited on desktop. This would pose the question 'what should be shown to desktop users on this page?'. This is because on desktop, the info section does not work like a separate page like it does on mobile. So if a user visited a /info page on desktop, what should be shown? Should we only account for mobile visits or something else? Should we make it so when you visit /info from desktop, it loads / with the info section already open?