Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rfc: migrate jsonPayload to consumer defined props api #3

Open
cdaringe opened this issue Jun 14, 2019 · 1 comment
Open

rfc: migrate jsonPayload to consumer defined props api #3

cdaringe opened this issue Jun 14, 2019 · 1 comment

Comments

@cdaringe
Copy link

problem

  • 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
<MyView foo={'bar'} />

// view as navigated by this api
<MyView jsonPayload={'{"foo": "bar"}} />

// maybe optimized:
navigate({ ..., props: { foo: 'bar' } })
<MyView foo={'bar'} /> // unchanged prop api

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!

@deepueg
Copy link
Collaborator

deepueg commented Jun 17, 2019

@cdaringe Thanks for the feedback. Agree with your suggestion as it takes away the extra logic to extract props. Will add this with the 2.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants