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
feat: adds redirect for 404 how tos #1225
feat: adds redirect for 404 how tos #1225
Conversation
|
||
describe('[Fail to find a How-to]', () => { | ||
const uuid = crypto.randomBytes(16).toString('hex') | ||
const howToNotFoundUrl = `/how-to/this-how-to-does-not-exist-${uuid}` |
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.
🤔 Perhaps unneccessary as I think the datastore is completely reset between test runs so there are unlikely to be any collisions due to leaky state between test runs.
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 should do (cypress by default clears localstorage and we have manual methods to clear indexeddb), we also use a custom prefix in case of tests running in parallel. That being said, no real harm to include
There are many reasons a how to may not be available on the server. Such as: * Deleted 🔥 * Renamed ✏️ In an effort to make the experience less of a dead end for the visitor we redirect them to the search page. This current implementation takes place on the client side after attempting to load a how-to entry from the backend data store. Reference: #1168
Visit the preview URL for this PR (updated for commit ab03241): https://onearmy-next--pr1225-feat-adds-redirect-f-38hqowj0.web.app (expires Thu, 04 Nov 2021 19:35:18 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
search: | ||
'?search=' + | ||
(this.props?.match?.params?.slug).replace(/\-/gi, ' '), | ||
}} |
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.
Tested this out and really like the functionality, nice idea to also replace the dashes and make it look more human-readable
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.
Thanks for the contribution, really nice addition to have.
From my side I really like this and think it works well. I'll quickly check in with Dave before merging to see if he has any strong opinions whether we should also display some sort of message (hopefully not, as that could get a tiny bit messier assuming we would need to pass an extra URL param to let the page know it was redirected to after failed search or some other means)
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.
Just to quickly note, as mentioned on the call would be good to have some sort of message to show to let users know that the howto they were searching for couldn't be found.
Feel free to draft/design any first pass at this that you want and once the PR is updated tag Dave in review for feedback on the design and if you have any concerns about the code feel free to tag me for re-review.
@davehakkens see below for a preview of how the search page looks if you arrive via a 404 how to link. I've changed the heading and introduced a sub header as an extra prompt for the user. Let me know what you think: |
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.
What a beautiful artwork @thisislawatts!
But yeh, looks neat :)
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.
One small issue I noticed, is that the source does not reset after navigation, and so the message stays there even after the user opens a howto and returns to a clean howto page (source no longer in URL). So maybe we need to move the check to the list page itself onComponentDidMount/useEffect hook, or just add something to the store to reset when setting an active howto?
When navigating back the URL changes to just be /howto but the message still exists - would be good to revert to standard page message
Precious.Plastic.Community.mp4
Thanks @chrismclarke, very helpful! The persistence of state is an existing behaviour which my change makes more visible 🤔 Try the following (desktop device):
Is that deliberate and designed behaviour? |
Oh, I see what you mean, the search param disappears but the box and search contents persist. No, none of this was active design choices and I don't think has been noticed up till now. I'm guessing probably easiest if we merge this in and create another issue to address? Unless there was any quick fix you wanted to apply - I'm assuming the expected functionality should be to take the URL bar as main source of truth, so that if navigating back via browser back button search will be retained in URL and UI, but if navigating by menu bar or other triggered methods URL and page will be clean state. But not sure how quick a fix this would be so happy to write-up in another issue if easier to manage that way |
Yes, I am still gaining context on the MobX module and state management, I found this interesting article entitled, How to decouple state and UI (a.k.a. you don’t need componentWillMount), from 2016. Interesting, but definitely not straight forward to implement if it's even a valid approach. My experience with SPA of this complexity is limited. So I am here to learn. |
In the meantime I will take a look at a hotfix |
Yeah no worries at all. I know the existing codebase is a bit messy around these things (we have lots of different lifecycle hooks used in different ways, some of which are now deprecated (e.g. componentWillMount vs componentDidMount vs UseEffect vs unsafe_componentWillReceiveProps etc.)), and mobx itself has had quite a few breaking changes moving through v4 -> v5 etc. So yeah, as long as you're having fun basically! In the long term any slow, incremental improvements will also be appreciated, and if you find while working on any of this stuff that there's particular pain points you come across feel free to reach out on slack and I can let you know if I can share any insights around it (always happy to try help speeding up learning curves). |
Useful context @chrismclarke, I've pushed a fix which uses the |
Nice - makes sense to me for now. There's still the issue that the search box contents persist across navigation (unrelated to this pr) so can just do the extra bit of refactoring when we turn to address that |
🎉 This PR is included in version 1.7.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
PR Checklist
master
branch mergedPR Type
Description
There are many reasons a how to may not be available
on the server. Such as:
In an effort to make the experience less of a dead
end for the visitor we redirect them to the search
page.
This current implementation takes place on the client
side after attempting to load a how-to entry from
the backend data store.
Git Issues
Reference: #1168
Closes #1227