Implement commenting and replying for mobile editor

[sachben91]

Description

This ticket describes the new user experience for commenting or replying to posts within mobile. Most of the behavior remains the same, with update to the editor component

Project Owner

PM: @zakhap @sachben91 Designer: @jessmart1213

Designs

Figma

Feature specs

• Commenting and replying would have the new editor component, rest of the behavior remains the same

[mzparacha]

I tested with iOS, Microsoft and Google keyboards and the "Input field transitioning above keyboard" works well in iOS chrome/safari and Android chrome.

Backstory -> we discussed in the kickoff if this was possible to do reliably with different keyboards.

cc: @CowMuon @zakhap @sachben91 @masvelio

[rbennettcw]

Looks like the input field will be a sticky footer, so it’ll stick to the bottom of the viewport, above the keyboard.

But the nav menu is also a sticky footer, so we might need to use onFocus/onBlur to conditionally hide it.

Feasible, but from dev standpoint, I can see some complications in needing to send input focus state up to the nav bar– similar issues we had with breadcrumbs. And for the fullscreen view, we’d want to hide the nav bar regardless of focus state?

[sachben91]

@rbennettcw for the full screen view of the editor we would want to hide the nav bar completely yes. For the complication you are referring to wrt replies - would it be a significantly high effort?

[rbennettcw]

@sachben91 AFAICT, there's actually no proper way to check if the virtual keyboard is open/closed. We can check the onFocus/onBlur events and the window resize event. But neither of those guarantee that the keyboard is open or not.

There are some 3rd party libraries that aim to solve the problem, but they typically have github issues that state "this doesn't work anymore" because of the hackiness of the solutions.

We should be prepared for the possibility that we may not be able to reliably detect keyboard state across all browsers.

[CowMuon]

Ryan surfaces a great point here, that given our hybrid (PWA) approach, we do not have any way of polling to see if keyboard drawer is open. Unlike native apps, that have that do have this capability. React native has the keyboard module and in Swift you have didShow and didHide events you can check.

But hybrid apps are forced to use indirect methods, such as using a media query to see if the window size changed, or event listening for resize events -neither of which turn out to be determinate- or there are, as Ryan mentions, 3rd party solutions, most all of which tend to be hacky or unmaintained.

Headline here is that Product-Design should not rely on being able to know whether the user's device keyboard is open or closed, without a tremendous eng effort, relative to what's needed here. Should prolly discuss in Design Crit.

[rbennettcw]

Estimating as a 5, assuming we won't spend too much time on the keyboard issue.

Just to confirm:

• When the comment is posted, it should essentially prepend the mention to the comment body, e.g. “@norf-the-admin …”?

Also, please confirm the functionality of the buttons under the comment input box. One looks like an image upload, but the other I'm not 100% sure the desired behavior.

[ForestMars]

@burtonator for visibility, TBD Monday 6/3 PENG office hours.

[ForestMars]

@mzparacha pairing with @burtonator who has the other story (both moved from old milestone into editor milestone for cycle 6)