Navigation API (2025-10): data flow between screens

Extensions
1

I’m trying to understand when and how to use Navigation API (2025-10).

My current setup (inspired by Navigation API):

  • Main screen (TransferSelection.jsx)
  • Transfer details (TransferDetail.jsx)
  • Line Item of transfer (TransferDetailItem.jsx)

So this is my Modal.jsx (pos.home.modal.render) that routes to the different screens.

function Extension() {
  const { url } = navigation.currentEntry

  if (url === '/TransferDetail') {
    return <TransferDetail />
  }

  if (url === '/TransferDetailItem') {
    return <TransferDetailItem />
  }

  return <TransferSelection />
}

I’m able to pass a state via navigation.navigate().
Example:

navigation.navigate('/TransferDetail', { state: { transferId: transfer.id } })

What is unclear to me is how to pass data e.g. to the previous screen

  • <TransferDetail> opens a screen for a line item
  • user adds information on <TransferDetailItem> (component state)
  • user navigates back (or clicks a button)
  • back on <TransferDetail> there’s a button that performs the transaction with all information the user added for multiple line items

So I can’t see a clean way to pass back data from <TransferDetailItem> to <TransferDetail>.

Probably such a screen isn’t meant to be used this way? And I shouldn’t think about using screens this way? Like using <TransferDetailItem> directly within <TransferDetail>

2

Hi @Jens_Simon

The Navigation API is designed for forward data flow only. There’s no built-in mechanism to pass data backward when navigating back to a previous screen. For your multi-step transfer workflow with multiple line items, the Storage API might be more appropriate.

1 Like
3

I see that Navigation API works pretty similar to handling state using History: pushState() method - Web APIs | MDN.

And it’s great that it’s totally in my own hands how to handle state.

Personally I try to avoid all of those state management libraries as long as possible.

For me the definition of a “Screen” is a bit unclear

  • when to open a new screen
  • how is it connected to it’s surroundings (parents, successors)
  • is the reason to open a new “screen” to separate a feature
  • …

I simply miss the answer for:

When should I need to navigate to another screen?

It’s also possible to implement the screen using conditional components so it’s possible to handle the data flow using React-Style.
But that way there is the problem how to handle the back button.

I see how pages are used within the POS app. So pages seems to be the way to go.

Current Solution

My current solution is pretty minimalistic. But works great.
And I don’t see a proper reason why it shouldn’t be valid.

function ScreenA() {
  const { value, setValue } = useState(undefined)
  const otherData = "Foo"

  return (
    <s-page heading="Screen A">
      <s-button
        onClick={() => {
          navigation.navigate('/TransferDetailItem', {
            state: {
              otherData,
              onValue: (valueFromScreen) => {
                setValue(valueFromScreen)
              }
            }
          })
        }}
      >
        <s-text>Show Screen B</s-text>
      </s-button>
      { value && (
        <s-text>{value}</s-text>
      )}
    </s-page>
  )
}

function ScreenB() {
  const {
    otherData,
    onValue,
  } = navigation.currentEntry.getState()

  return (
    <s-page heading="Screen B">
      <s-text>{otherData}</s-text>
      <s-button
        onClick={() => {
          onValue('Hello World')
        }}
      >
        Send data to Screen A
      </s-button>
    </s-page>
  )
}
  • callback function onValue is passed to the navigation state for <ScreenB>
  • to send data back <ScreenA> the onValue callback is used

It’s a local in-memory state. Should work for the real world task.

Storage API

But while thinking about the real world task it probably makes a lot of sense to think about using the Storage API.

What happens

  • if the POS app user gets interrupted during using the POS extension?
  • with the local state after leaving the device?

How long will the local state be alife?

So probably it’s necessary to use the Storage API.
And to have some housekeeping in mind because of the limitations (which are totally legit)