title: React/Redux pattern for demoable apps
body: <p>I've been searching around for a while on this, but as of yet haven't found anyone else trying it. So I'm asking for feedback and critique - both on if this seems reasonable, and if there's a better established pattern for it.</p>
  
  <p>Basically, I want to be able to easily publish a "demo" version of a react/redux app. My specific example is an app I built but that is only useable with our internal database with user information. I can't show that anywhere, because we don't want the information to escape out into the world.</p>
  
  <p>Since all of the model interactions are routed through redux, it occurred to me that I could drop in a new set of actions based upon the URL.</p>
  
  <p>Say the user goes to myawesomeapp.com - they're given the full app, login prompts, security, access to the database.</p>
  
  <p>But an outside party could go to demo.myawesomeapp.com (for example), and get an app that is functionally the same but is wired up to dummy data that isn't saved.</p>
  
  <p>The general pattern that I have would be this:</p>
  
  <p>Vaguely, in actions/index.js</p>
  
  <pre><code>export * from './common_actions';
  if (location.href.match(/demo\.myawesomeapp\.com/)) {
    export * from './demo_actions';
  }
  else {
    export * from './actions';
  }
  </code></pre>
  
  <p>I don't really like that - it feels brittle and like a hack. But it works! Registered users can use the actual app, and demo users can try it out in a sandbox.</p>
  
  <p>Judicious use of exported constants and values also allow peppering of other flags and data - overlays of text to walk through things, links to sign up for the actual app, etc.</p>
  
  <p>I love this as a concept - with just a few new redux actions, you get a fully sandboxed app to show off with no worry of cross contamination. It's much easier than trying to sanitize all the endpoints.</p>
  
  <p>And even if an action wasn't properly isolated in this manner, the worst that would happen is that they'd get an access denied error from the actual backend since they're not logged in.</p>
  
  <p>But to the world, my questions are -</p>
  
  <p>1) Does this seem like a reasonable thing to do or are there gotchas I'm not considering it?</p>
  
  <p>2) Does this seem like a reasonable way to implement it, or is there a better approach I haven't considered? </p>