Documentation Vote

[verdverm]

Pick your top three choices, I will work on some set of them.

Some starting points ( #589 and the docs dir )

Also note, this repository does not have a stable API yet (@Vlasenko please confirm, there is that stable branch).

[larixer]

@verdverm This repository is not a library to have a stable API, so I disagree here. This repository is a starter kit for cross-platform projects and production-ready graphql projects for mobile, web and server can be crafted with the help of this repository.

[verdverm]

I'm kind of thinking that once things are more modular (and coming from external sources),
that it would be up to a group of modules working together to document how to use them (which would include how they are used with this repository).

Did you see #648 ? What are your thoughts on that?

[larixer]

@verdverm Yes I saw it. Looks certainly interesting!

[leviwheatcroft]

Sorry I don't really have a vote right now, a few thoughts though:

docs/readme is kind of a list of things that need to be documented, so docs/wishlist seems kind of redundant?

Also, is a docs folder the best approach for documentation ? Seems to be a really popular approach currently though IDK why. Any benefits to using a wiki instead?

Personally I find annotated code with a renderer like docco a really helpful complement to a wiki, it reduces the verbosity of other documentation by minimising duplication.

[leviwheatcroft]

Additionally, when we're talking about 'documentation' are we talking about documenting how the code works? Or guides about how to implement different things?

The latter might be great down the track, but I'd have though the former would be a priority in the short term.

[verdverm]

I think people are having a hard time picking up the project, which hurts adoption. I think documentation keeps coming up because of this. People have asked many times in issues and gitter.

And... it's hurting adoption, so I would agree it's of some priority.

I think maybe we start with some high-level descriptions:

• How the build works, and relates to the packages/*
• How the client/server gets put together / bootstrap / startup
• How modules / features / connectors work
• Overview of the directories and important files

Thing is though, some of this will become [application starting package whatever...] dependent.
I've started some high level documentation here, but the architecture of the application has been flipped inside out. (also depends on if #651 is adopted)

But again, it's hurting adoption and we all wish we took (felt like we had) more time to document. The fact that it keeps coming up is a signal the docs are deficient. Maybe we prioritize by what is stable? (not sure I know what is or isn't myself) ok, done ranting

[leviwheatcroft]

I think documenting feature is the obvious place to start, if you want to clone the repo and play around that's the first thing you'll come up against. Lots of discussion in #565.

[verdverm]

@adam-s b.t.w. I think (it is why I do) the reason people like a docs folder and markdown is because the github+markdown acts like a website, and maybe more importantly, I can write in my usual text editor (vim).

I do like the way godoc works, with code introspection to create some amount of docs even if none are written by anyone. Is there anything like that for JavaScript?

[snowman-repos]

For running Android or iOS you need to set in .spinrc.js builders.ios.enabled and/or builders.android.enabled field true.

For someone who's never used spinjs before I'm struggling with this one... it's not clear where to put what exactly. Surely running Android or iOS is a key feature of this kit, but so far I'm not able to get it working.

[larixer]

@darryl-snow You should change false to true here:

apollo-universal-starter-kit/packages/mobile/.spinrc.js

Line 13 in 129ace8

enabled: false

in order to enable Android target.

And to enable iOS target, put true in the same file here:

apollo-universal-starter-kit/packages/mobile/.spinrc.js

Line 23 in 129ace8

enabled: false