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
on launch of our application, our RN entrypoints inject prop key-value pairs, per idiomatic react declarative view-isms, which is normal and good. the navigate API currently expects a key called jsonPayload, which passes a new prop that all routable views have to consider. there's a dev nicety or potential optimization to reduce consumer overhead by aligning jsonPayload with existing, expected props
example
// default view<MyViewfoo={'bar'}/>// view as navigated by this api<MyViewjsonPayload={'{"foo": "bar"}} />
// maybe optimized:navigate({ ...,props: {foo: 'bar'}})<MyViewfoo={'bar'}/>//unchangedpropapi
discussion
it would be ideal to:
have the runtime parse the json on behalf of consumers--stringify and parse on our behalf
inject KV pairs in as props, as named by the navigate call
this API could be a non-breaking change, additional key, and enable us to route using props in a more familiar fashion. e.g. navigate({ ..., props: { foo: 'bar' }).
in the web, view state is a function of both:
props and
url state (origin, path, query, etc)
this API only injects state directly into the root view. if we are injecting state directly into the view, it seems worthwhile to just align with the existing consumer prop APIs. alternatively, just done in web, a nice alt approach would be to expose the current routing state synchronously in the JS context. both of these approaches i think would lower cognitive overhead, and yield an improved experience.
thanks for the consideration!
The text was updated successfully, but these errors were encountered:
problem
jsonPayload
with existing, expected propsexample
discussion
it would be ideal to:
this API could be a non-breaking change, additional key, and enable us to route using props in a more familiar fashion. e.g.
navigate({ ..., props: { foo: 'bar' })
.in the web, view state is a function of both:
this API only injects state directly into the root view. if we are injecting state directly into the view, it seems worthwhile to just align with the existing consumer prop APIs. alternatively, just done in web, a nice alt approach would be to expose the current routing state synchronously in the JS context. both of these approaches i think would lower cognitive overhead, and yield an improved experience.
thanks for the consideration!
The text was updated successfully, but these errors were encountered: