Skip to content

Conversation

robin-macpherson
Copy link
Contributor

@robin-macpherson robin-macpherson commented Nov 30, 2021

Description

Issue:

Welcome to a delightful, fun feature that simply adds a sweet and delightful edge to the Journaly writing experience: typewriter sounds! Because why not!? Basically, if a user turns this feature on then they'll simply hear the delightful clickity-clacks of a typewriter with each key press ⌨️ ❤️

Also takes care of some important work that will become useful in other upcoming PRs:

  • Builds a <SwitchToggle /> Component which will be very handy for quickly toggling on and off features
  • Fixes our long-standing bug where the mobile editor toolbar overruns its container, implementing a more flexible layout

Subtasks

  • I have added this PR to the Journaly Kanban project ✅
  • Implement sound effect on typing
  • Figure out issue with sounds not playing in quick succession
  • Figure out issue with sounds not playing in very quick succession 😅
  • Figure out issue with playSounds state not updating correctly in some places
  • Build SwitchToggle Component
  • Implement toggling in the editor
  • Fix responsive layout issues
  • Decision: Premium or not?
  • Translations
  • Handle refocusing & holding position on formatting (Moved to separate ticket)
  • Save toggle state (should just be able to drop in useAutosavedState)
  • Fix slight delay between when sticky kicks in and fixed class gets added
  • Rename toolbarRef
  • Observer cleanup (when we unmount let's clean up the observer)
  • try clean up dashboardConstants
  • Some kind of handling for browsers that don't have observer support (wrap in try-catch)
  • Figure out the gotcha with typing on mobile 😩

Deployment Checklist

  • 🚨 Deploy code to stage
  • 🚨 Deploy code to prod

Migrations

No miggies.

Screenshots

1. Toolbar with Typewriter Sounds OFF

Screenshot 2021-11-30 at 11 59 06

2. Toolbar with Typewriter Sounds ON

Screenshot 2021-11-30 at 11 59 23

@vercel
Copy link

vercel bot commented Nov 30, 2021

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/journaly/journaly/DwEA2AcxaYwNysroRRWgVs52dRL8
✅ Preview: https://journaly-git-type-writer-sounds-journaly.vercel.app

@robin-macpherson robin-macpherson self-assigned this Nov 30, 2021
@robin-macpherson robin-macpherson added FEATURE New feature or request frontend Frontend work! j-editor labels Nov 30, 2021
Co-authored-by: LindasLinguas <92399187+LindasLinguas@users.noreply.github.com>
@robin-macpherson robin-macpherson changed the title J-Editor / FEATURE: Typewriter Sounds! ⌨️ J-Editor / FEATURE: Typewriter Sounds! 🎵 Dec 27, 2021
@vercel
Copy link

vercel bot commented May 6, 2022

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated
journaly ✅ Ready (Inspect) Visit Preview May 17, 2022 at 3:00PM (UTC)

Copy link
Contributor

@Lanny Lanny left a comment

Choose a reason for hiding this comment

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

This is looking in quite good shape. I thought with all the fiddling with keyboard hacks we'd have some more spaghetti in here but it's pretty lean and clean all things considered.

const windowSize = useGetWindowSize()

// This is to accounnt for the nav which appears at the top on mobile and has a height of 72px
const toolbarStickyOffset =
Copy link
Contributor

Choose a reason for hiding this comment

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

since we un-fixed the nav, is this still necessary? Can we make rootMargin a constant -20px 0 0 0?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! Removed this and related code ✅

Comment on lines +72 to +74
const onVisualViewportChange = () => {
setViewportsDiff(visualViewport.offsetTop)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I kinda think we should debounce this for performance purposes, maybe with an interval of half or a quarter of a second, for performance purposes. But I don't know how much of an impact that's going to have on the feeling while scrolling. There's already some inevitable latency in there so maybe not too bad?

If you have a chance maybe test it with and without the debounce and see if it makes a big difference. But not a blocker.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Going to do this as a quick followup so that I can also refactor other places where we debounce too 👍🏼

Co-authored-by: Ryan Jenkins <2343714+Lanny@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FEATURE New feature or request frontend Frontend work! j-editor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

⌨️ J-EDITOR: Optional Typewriter Sounds Mobile editor buttons overrun their container
3 participants