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

Carry over ft query param while navigating #174

Open
jwicks31 opened this issue Aug 6, 2018 · 1 comment
Open

Carry over ft query param while navigating #174

jwicks31 opened this issue Aug 6, 2018 · 1 comment

Comments

@jwicks31
Copy link
Contributor

jwicks31 commented Aug 6, 2018

Would be nice for the ft query param to carry over while navigating the site.

Example:

I'm in http://localhost:3001/?ft=nav-buttons,footer,register,auth
I click on the Sign Up button
I'd like to be taken to http://localhost:3001/register?ft=nav-buttons,footer,register,auth
I'm instead directed to http://localhost:3001/register, which shows nothing at the moment

Labeling this as testing because that's where I'd use it, personally.

Implementation
I'm guessing the simplest option would be to use localstorage as the single source of truth for the value of ft, updating only it if ft is present.

@kennylavender
Copy link
Contributor

Persistence of the ft query is something I've been pondering about for a while, but haven't had time to test any ideas.

localstorage could work, here are some concerns I have.

  1. it's not very explicit to the person testing/reviewing as they transition through pages that a feature is enabled or not.
  2. it means we would need to provide a way to turn off features manually or localstorage would need to be cleared after features were enabled. Manually disabling them from the URL would be very annoying.

Both of the above issues could be eased by adding a UI, as suggested in #173 , but I also have a few concerns about adding a UI.

  • We can't show available features to enable from the UI, Eric purposly made sure I avoided exposing features to the user that could be enabled.
  • We don't want to show features that are currently active by default because we don't want those turned off.
  • So really we would only be showing features activated by the query, it could just be a convenient way of disabling them if they are in local storage.
  • Dev UI's, I've always liked the idea, but always had issues with implementation. Have yet to see a dev UI's that succeeds in staying out of the way and does not interfere with theming/design, that includes overlays and header/footer UI's.

The idea I have been working on was creating a function that needs to be applied to every URL in the app that needs to respect ft params.

// current window location = www.domain.com/baz?ft=apple,orange
const MyComponent = () => (
  <div>
    <Link to={addFeatureToggleParams('/foo/bar')} /> // www.domain.com/foo/bar?ft=apple,orange
  </div>
);

It could also be used for react router to objects

// current window location = www.domain.com/baz?ft=apple,orange
const MyComponent = () => (
  <div>
    <Link to={{ pathname: '/foo/bar', search: addFeatureToggleParams('') }} /> // www.domain.com/foo/bar?ft=apple,orange
  </div>
);

Preferably this function would be hidden inside an app helper or something that would be used for all internal URLs. The benefit of this we can add/remove functionality as needed for the app URLs from the one function.

import { createURL } from 'helpers'
// current window location = www.domain.com/baz?ft=apple,orange
const MyComponent = () => (
  <div>
    <Link to={createURL('/foo/bar')} /> // www.domain.com/foo/bar?ft=apple,orange
  </div>
);

Another benefit is that this function could also be applied to API paths so that we can send the correct feature toggle signals to the API to support additional endpoints etc.

Not sure which idea is better or if there is an even better solution, but we do need one. Input would be appreciated.

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

No branches or pull requests

2 participants