Buttons vs Links

[axyz]

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.tsx
const getResourceURL = (resource) => // get the web url

// get-resource-url.native.tsx
const getResourceURL = (resource) => // get the app url

// navigation-component.tsx
const NavigationComponent = ({resource, ...rest}) => 
  <h.a href={getResourceURL(resource)} {...rest} />

// navigation-component.native.tsx
const NavigationComponent = ({resource, ...rest}) => 
  <compat.native {...rest} />
    {(nativeProps) =>
      <Pressable onClick={() => 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.

[abdulmalik-codeWithFaith]

I think keeping navigation as a separate abstraction makes more sense than making html.a handle both cases. On web, a real should keep normal browser behavior like opening in a new tab, copying the URL, and accessibility. On native, navigation is screen-based, so trying to make href handle both could become confusing.

A shared Link component could expose a common API while using on web and the native navigation component on React Native. The shared component could accept something like a resource/route rather than forcing every consumer to know how that resource becomes a web URL or native route.

That also keeps the platform-specific routing logic out of the UI components.