Merge pull request VulcanJS#74 from amandeepmittal/master

Changes in 7 docs

source/field-resolvers.md

@@ -2,13 +2,13 @@
 title: Field Resolvers
 ---
 
-Although Vulcan uses your SimpleSchema JSON schema to generate your GraphQL schema, it's important to understand that the two can be very different. 
+Although Vulcan uses SimpleSchema JSON schema to generate a GraphQL schema, it's important to understand that the two can be very different.
 
 Note: this section will make more sense if you've already read the [Resolvers](/resolvers.html) section.
 
 ## Overview
 
-For example, you might have a `userId` property in your `Movie` schema, but want this property to *resolve* as a `user` object in your GraphQL schema (and in turn, in your client store). You can use `resolveAs` to accomplish this:
+For example, you might have a `userId` property in your `Movie` schema, but then you want this property to _resolve_ as a `user` object in the GraphQL schema (and in turn, in your client store). You can use `resolveAs` to accomplish this:
 
 ```
 userId: {
@@ -33,16 +33,15 @@ We are doing five things here:
 2. Specifying that the field can take a `foo` argument that defaults to `10`.
 3. Specifying that the `user` field returns an object of GraphQL type `User`.
 4. Defining a `resolver` function that indicates how to retrieve that object.
-5. Specifying that the original field (`userId`, with type `String`) should also be added to our GraphQL schema. 
+5. Specifying that the original field (`userId`, with type `String`) should also be added to our GraphQL schema.
 
-Note that it is recommended that you pick a **different** name for the "real" database field (`userId`) and the field in your schema (`user`), especially if you set `addOriginalField` to `true`. This way, you will be able to unambiguously require either the `_id` or the full user object just by specifying which field you need. 
+Note that it is recommended that you pick a **different** name for the "real" database field (`userId`) and the field in your schema (`user`), especially if you set `addOriginalField` to `true`. This way, you will be able to unambiguously require either the `_id` or the full user object just by specifying which field you need.
 
 Also, the resolved type is a GraphQL type, not a primitive type or a schema. Therefore, it must necessarilly be a string (`'User'` in the previous example). If you rather need an array of user, the resolved type will be `'[User]'`. For primitive types, you must provide the name as a string, instead of the constructor : `'Date'` for a `Date`, `'String'` for a `String` etc.
 
-
 ## Custom Types
 
-Creating a collection with `createCollection` will automatically create the associated GraphQL type, but in some cases you might want to resolve a field to a GraphQL type that doesn't correspond to any existing collection. 
+Creating a collection with `createCollection` will automatically create the associated GraphQL type, but in some case you might want to resolve a field to a GraphQL type that doesn't correspond to any existing collection.
 
 Here's how the `vulcan:voting` package defines a new `Vote` GraphQL type:
 
@@ -53,18 +52,18 @@ const voteSchema = `
     power: Float
     votedAt: String
   }
-  
+
   union Votable = Post | Comment
 `;
 
 addGraphQLSchema(voteSchema);
 ```
 
-Which can then be used as the value for `type` in a `resolveAs` field. 
+Which can then be used as the value for `type` in a `resolveAs` field.
 
 ## GraphQL-Only Fields
 
-Note that a field doesn't have to “physically” exist in your database to be able to generate a corresponding GraphQL field. 
+Note that a field doesn't have to “physically” exist in your database to be able to generate a corresponding GraphQL field.
 
 For example, you might want to query the Facebook API to get the number of likes associated with a post's URL:
 
@@ -82,9 +81,9 @@ likesNumber: {
 },
 ```
 
-This will create a `likesNumber` field in your GraphQL schema (and your Apollo store) even though no such field has to exist in your database. 
+This will create a `likesNumber` field in your GraphQL schema (and your Apollo store) even though no such field has to exist in your database.
 
-Note that for GraphQL-only fields, it's ok to leave out the `fieldName` property (which will default to using the same name as the schema field) since there is no actual database field of the same name. 
+Note that for GraphQL only fields it is ok to leave out the `fieldName` property (which will default to using the same name as the schema field) since there is no actual database field of the same name.
 
 ## Legacy String Syntax (deprecated)
 
@@ -96,9 +95,14 @@ import { addGraphQLResolvers } from 'meteor/vulcan:core';
 const movieResolver = {
   Movie: {
     user(movie, args, context) {
-      return context.Users.findOne({ _id: movie.userId }, { fields: context.getViewableFields(context.currentUser, context.Users) });
-    },
-  },
+      return context.Users.findOne(
+        { _id: movie.userId },
+        {
+          fields: context.getViewableFields(context.currentUser, context.Users)
+        }
+      );
+    }
+  }
 };
 addGraphQLResolvers(movieResolver);
 ```

source/fragments.md

@@ -2,8 +2,7 @@
 title: Fragments
 ---
 
-
-A fragment is a piece of schema, usually used to define what data you want to query for. 
+A fragment is a piece of schema, usually used to define what data you want to query for.
 
 ## Registering Fragments
 
@@ -60,16 +59,19 @@ You often need to add one or more properties to a fragment without modifying its
 ```js
 import { extendFragment } from 'meteor/vulcan:lib';
 
-extendFragment('PostsList', `
+extendFragment(
+  'PostsList',
+  `
   color # new custom property!
-`);
+`
+);
 ```
 
-This is the same as registering the entire `PostsList` fragment with `color` tacked on at the end. 
+This is the same as registering the entire `PostsList` fragment with `color` tacked on at the end.
 
 ## Replacing Fragments
 
-To replace a fragment completely, you can just register it again under the same name. 
+To replace a fragment completely, you can just register it again under the same name.
 
 ```js
 import { registerFragment } from 'meteor/vulcan:lib';
@@ -92,8 +94,8 @@ Note that you can replace both “regular” fragments and sub-fragments.
 
 Every collection automatically gets a default fragment associated with it called `FooDefaultFragment` (for example `PostsDefaultFragment`).
 
-This default fragment simply contains all fields where `viewableBy` is defined (in other words, all public fields). Note that it **does not** follow field resolvers, meaning that the default fragment will e.g. include `userId` but not `user`. 
+This default fragment simply contain all fields where `viewableBy` is defined (in other words, all public fields). Note that it **does not** follow field resolvers, meaning that the default fragment will e.g. include `userId` but not `user`.
 
 #### Alternative Approach
 
-You can use standard Apollo fragments at any point in your Vulcan app (passing them as `fragment` instead of `fragmentName`), but be aware that you will lose the ability to extend and replace fragments. You will also need to  [manually specify](http://dev.apollodata.com/react/fragments.html#reusing-fragments) sub-fragments. 
+You can use standard Apollo fragments at any point in your Vulcan app (passing them as `fragment` instead of `fragmentName`), but be aware that you will lose the ability to extend and replace fragments. You will also need to [manually specify](http://dev.apollodata.com/react/fragments.html#reusing-fragments) sub-fragments.