Is the 'remove-demo' script maybe a little over-zealous?

Okay, so I admit up-front: yes, user error. I should have been more careful. But I just found out the hard that the ‘remove-demo’ script removes more or less everything. I left the demo files in while I started working so that I could have a reference as to how things are wired up and such. After getting my head around it, I ran the script only to find that it deleted pretty much everything.

FWIW, this is not a “real” project I’m working on–mostly just trying to get my head around Slingshot, so it’s not like it’s a huge deal for me or anything. But looking at the script, this part seems like it might be a little overkill, as it seems to assume that the user has not already added any of their files to any of these directories:

const pathsToRemove = [
  './src/actions/*',
  './src/businessLogic',
  './src/components/*',
  './src/constants/*',
  './src/containers/*',
  './src/images',
  './src/reducers/*',
  './src/store/store.spec.js',
  './src/styles',
  './src/routes.js',
  './src/index.js'
];

I’m wondering if it should either be updated to list the specific files that need to be deleted, or maybe even just add a note in the pertinent FAQ section warning users about how thorough this is? I would hate to someone lose “real” work because they were stupid enough to do what I did. 😃

I also wonder if index.js needs to be listed at all, since it is really already pretty generic and universal as it is?

[raythree]

@mikedevita, I agree that it sucks to have to rewire the index, store, reducers, etc. to get a working starter. I know how all this stuff works, but sometimes I’m working on backend server-side stuff and can go weeks or months not doing UI work. So it’s a pain to need to remember how to wire everything up!

Slingshot is awesome, well maintained, and carefully thought out. So I want to simply clone the latest version and start using it for each new project. Before I was cloning it and making modifications to fit my structure. I’ve been away for a while and found that a good deal had changed, including using Jest instead of Mocha.

@kwelch, I think the solution is to leave the remove-demo script exactly as it is. People can create their own starter apps that are structured exactly the way they want, and then drop that in after removing the demo. This is exactly what I did here:

https://github.com/raythree/slingshot-hello

So now I can grap the latest react-slingshot, with all the up-to-date enancements, and drop in my own app structure that I can turn into the start of a production app in under a minute, with minimum edits.

[raythree]

@kwelsch if you take a look at the src folder of the repo I listed above you will see pretty much the exact minimum number of files that you need to create after remove-demo, to get a fully functioning app (with routes, a store, and functioning sync and async actions). The only file there that already existed was src/store/configureStore.

Leaving configureStore was a good choice, because it does a lot of configuration for dev and production environments, and all you really need to do with it is add any middleware that you choose.

Everything else is pretty much application specific. While the ideal goal would be to have 1 component, 1 container, and 1 test case ready to go like the starter that I’m using, there is no scheme that will satisfy everyone. For example, I prefer a functional layout to the layout by type because I find it scales better for larger apps. I also like the tests in a separate (mirrored) directory.

So, I think as it stands “remove-demo” is perfect.