Documentation Wish List

[larixer]

This is a placeholder issue to list wishes from the users of the kit where the documentation should be improved. We will accumulate all wishes on documentation here. Please try to not mix simple to document things with thing that will require much more effort to document. And take into account that more simple documentation tweaks will highly likely be addressed first.

[H1net]

This is a tough one for me as the nature of the project makes me reticent to suggest things that are beyond the scope of the individuality of the project... but really this project is all about connecting things together to create a viable stack and pattern for rapid production? So do we just document everything that slows down production as a kind of "Getting Started" set of docs? I was looking at my toggl timesheets and I am ashamed of how much time I spent on some of the simplest things coming over from meteor development previously.

• [ ] Loading additional assets
• [ ] Using icons libraries (Native and web)
• [ ] Switching to MySQL / GraphQL
• [ ] Selecting/Installing simulator for iOS
• [ ] Auth... thank god for the recent pulls. More documentation is needed though, including examples of using the new AuthRoute etc. to define your routes with roles. For example I ended up having to edit the AuthRoute to pass additional props to Render for my views that use the same HOC
• [ ] This sounds trivial, but people should be told to uncomment .env from their .gitignore?
• [ ] Where should I put my generic assets (scss, etc.)... it took me a while before I moved stuff out of the ui-bootstrap folder in src/client/modules/common/web to their own folders.
• [ ] Migration files and seeding - Especially with foreign key constraints. Doing knex.createTable ... then() etc.. MySQL has tighter constraints than sqlite too so once I migrated I had to move my foreign key creation to happen after all dependencies were settled to ensure safe rollback.
• [ ] Date scalars in graphql
• [ ] UTC/vs local time usage, god bless moment (which btw is available in the kit as a dependency of something else I think but is not actually in package.json)

[larixer]

@H1net Yes, we create viable stack and pattern for rapid production. Yes, we need to document everything that slows going to production.

No, users are not advised to uncomment .env from their .gitignore. You should not put your production password and credentials into .env to not commit them into git by mistake. Thats why .env has been added to .gitignore to protect users from accidental commit of their passwords to git repo which might not be a safe place for this sensitive information.

[mitjade]

@vlasenko Maybe we should commit ‘.env.default’, so you can then fill in yor data and rename it.

[verdverm]

.env.sample might be a better name as it implies it needs to be filled in and renamed before it can be used. It would be good to have .env in the gitignore