You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When comparing web with native platforms, the usage of buttons and link (html.a) is quite different.
The rules below are not always set in stone and, at times, controversial. But on a high level they are more or less consistent across web and apps.
Web
Links are <a href=...> tags, and they "navigate" to a different page. Navigation happen via the href url and is implemented by the browser (no need to have an onClick triggering a navigate event)
Buttons are <button>, or <input type="button> or some custom div with appropriate roles. Buttons are used for "in page actions" (opening a menu, submitting a form, like a post, add to card, etc.)
Web (SPA)
Single Page Applications follow a similar logic on a semantic level, but technically there are different possible approaches, e.g.
exactly like web, but using hash based hrefs and some routing
buttons with role="navigation"
etc?
Native / React Native
A native app is close to an SPA, everything is a "button" and click handler deal with app routing as needed. "External" links are more rare, kind of alike target="_blanck" on web, opening an external app or the browser.
Implication in a Universal React Strict DOM Application
To keep things as semantic as possible and to be able to support URL based navigation, it becomes difficult to choose what to use where and how.
Let's imagine we have some kind of protocol to link to certain resources and a service can translate that to a web URL or an in app location.
Now if we have a page, for example a catalog of product cards. When clicking on a card we expect that:
on web it navigates to the specific product page (different url)
on native it navigates to a different screen (same app)
Technically this would normally be implemented roughly like:
on web: an <a href={URL}>
on native: a <Pressable onClick={navigateTo(APP_URL) or similar
This is an extremely common use case, and I'm wondering what is the most idiomatic way to tackle it in React Strict DOM.
I've been thinging to have some kind of abstraction like
// get-resource-url.tsxconstgetResourceURL=(resource)=>// get the web url// get-resource-url.native.tsxconstgetResourceURL=(resource)=>// get the app url
// navigation-component.tsxconstNavigationComponent=({resource, ...rest})=><h.ahref={getResourceURL(resource)}{...rest}/>// navigation-component.native.tsxconstNavigationComponent=({resource, ...rest})=><compat.native{...rest}/>{(nativeProps)=><PressableonClick={()=>navigate(getResourceURL(resource))}{...nativeProps}/>}</compat.native>
// Not sure here if pressable is the best option? How to ensure consistent DOM structure and styling is also something to be addressed
Probably missing some details and edge cases, but you get the gist. Additionally there may be a number of use cases where the "link" could be a textual element or a complex container.
I'm curious how this problem is being solved elsewhere, if there is a recommended more elegant approach, and also what is the general feeling in having to basically always hide the html.a to the consumer this way. Could/Should html.a handle this internally? Even though I can't see what a clean API for it would look like if the props should only contain href as a string, as different application may have very different logic on how to turn that on a click action.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
When comparing web with native platforms, the usage of buttons and link (html.a) is quite different.
The rules below are not always set in stone and, at times, controversial. But on a high level they are more or less consistent across web and apps.
Web
Links are
<a href=...>
tags, and they "navigate" to a different page. Navigation happen via the href url and is implemented by the browser (no need to have anonClick
triggering a navigate event)Buttons are
<button>
, or<input type="button>
or some custom div with appropriate roles. Buttons are used for "in page actions" (opening a menu, submitting a form, like a post, add to card, etc.)Web (SPA)
Single Page Applications follow a similar logic on a semantic level, but technically there are different possible approaches, e.g.
Native / React Native
A native app is close to an SPA, everything is a "button" and click handler deal with app routing as needed. "External" links are more rare, kind of alike
target="_blanck"
on web, opening an external app or the browser.Implication in a Universal React Strict DOM Application
To keep things as semantic as possible and to be able to support URL based navigation, it becomes difficult to choose what to use where and how.
Let's imagine we have some kind of protocol to link to certain resources and a service can translate that to a web URL or an in app location.
Now if we have a page, for example a catalog of product cards. When clicking on a card we expect that:
Technically this would normally be implemented roughly like:
<a href={URL}>
<Pressable onClick={navigateTo(APP_URL)
or similarThis is an extremely common use case, and I'm wondering what is the most idiomatic way to tackle it in React Strict DOM.
I've been thinging to have some kind of abstraction like
Probably missing some details and edge cases, but you get the gist. Additionally there may be a number of use cases where the "link" could be a textual element or a complex container.
I'm curious how this problem is being solved elsewhere, if there is a recommended more elegant approach, and also what is the general feeling in having to basically always hide the
html.a
to the consumer this way. Could/Shouldhtml.a
handle this internally? Even though I can't see what a clean API for it would look like if the props should only contain href as a string, as different application may have very different logic on how to turn that on a click action.Beta Was this translation helpful? Give feedback.
All reactions