Merge pull request #2175 from abhaynikam/remove-blue-notice-for-class-based-api

Robert Mosolgo · web-flow · commit 588c2fde44ca · 2019-03-09T09:33:47.000-05:00
Removed blue notice bar which prompts about New class based API
diff --git a/guides/_layouts/guide.html b/guides/_layouts/guide.html
@@ -18,17 +18,6 @@
     </p>
   </div>
 {% endif %}
-{% if page.class_based_api %}
-  <div class="class-based-header">
-    <p>
-      <strong>⚠ New Class-Based API ⚠</strong>
-    </p>
-    <p>
-      This describes a new API in <code>v1.8.0</code>.
-      Check the <a href="/schema/class_based_api">upgrade notes</a> for more info.
-    </p>
-  </div>
-{% endif %}
 {% if page.pro %}
   <div class="pro-header">
     <p>
diff --git a/guides/fields/arguments.md b/guides/fields/arguments.md
@@ -6,7 +6,6 @@ section: Fields
 title: Arguments
 desc: Fields may take arguments as inputs
 index: 10
-class_based_api: true
 ---
 
 Fields can take **arguments** as input. These can be used to determine the return value (eg, filtering search results) or to modify the application state (eg, updating the database in `MutationType`).
diff --git a/guides/fields/resolvers.md b/guides/fields/resolvers.md
@@ -6,7 +6,6 @@ section: Fields
 title: Resolvers
 desc: Reusable, extendable resolution logic for complex fields
 index: 9
-class_based_api: true
 redirect_from:
   - /fields/functions
 ---
diff --git a/guides/mutations/mutation_classes.md b/guides/mutations/mutation_classes.md
@@ -5,7 +5,6 @@ search: true
 section: Mutations
 title: Mutation Classes
 desc: Use mutation classes to implement behavior, then hook them up to your schema.
-class_based_api: true
 index: 1
 redirect_from:
   - /queries/mutations/
diff --git a/guides/mutations/mutation_root.md b/guides/mutations/mutation_root.md
@@ -5,7 +5,6 @@ search: true
 section: Mutations
 title: Mutation Root
 desc: The Mutation object is the entry point for mutation operations.
-class_based_api: true
 index: 0
 ---
 
diff --git a/guides/schema/class_based_api.md b/guides/schema/class_based_api.md
@@ -5,7 +5,6 @@ search: true
 section: Schema
 title: Class-based API
 desc: Define your GraphQL schema with Ruby classes (1.8.x alpha releases)
-class_based_api: true
 index: 10
 ---
 
diff --git a/guides/schema/definition.md b/guides/schema/definition.md
@@ -5,7 +5,6 @@ search: true
 section: Schema
 title: Definition
 desc: Defining your schema
-class_based_api: true
 index: 1
 ---
 
diff --git a/guides/schema/introspection.md b/guides/schema/introspection.md
@@ -5,7 +5,6 @@ search: true
 title: Introspection
 section: Schema
 desc: GraphQL has an introspection system that tells about the schema.
-class_based_api: true
 index: 2
 ---
 
diff --git a/guides/type_definitions/directives.md b/guides/type_definitions/directives.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Directives
 desc: Special instructions for the GraphQL runtime
 index: 10
-class_based_api: true
 experimental: true
 ---
 
diff --git a/guides/type_definitions/enums.md b/guides/type_definitions/enums.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Enums
 desc: Enums are sets of discrete values
 index: 2
-class_based_api: true
 ---
 
 Enum types are sets of discrete values. An enum field must return one of the possible values of the enum. In the [GraphQL Schema Definition Language](https://graphql.org/learn/schema/#type-language) (SDL), enums are described like this:
diff --git a/guides/type_definitions/extensions.md b/guides/type_definitions/extensions.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Extending the GraphQL-Ruby Type Definition System
 desc: Adding metadata and custom helpers to the DSL
 index: 8
-class_based_api: true
 redirect_from:
   - /schema/extending_the_dsl/
 ---
diff --git a/guides/type_definitions/field_extensions.md b/guides/type_definitions/field_extensions.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Field Extensions
 desc: Programmatically modify field configuration and resolution
 index: 10
-class_based_api: true
 ---
 
 {{ "GraphQL::Schema::FieldExtension" | api_doc }} provides a way to modify user-defined fields in a programmatic way. For example, Relay connections are implemented as a field extension ({{ "GraphQL::Schema::Field::ConnectionExtension" | api_doc }}).
diff --git a/guides/type_definitions/input_objects.md b/guides/type_definitions/input_objects.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Input Objects
 desc: Input objects are sets of key-value pairs which can be used as field arguments.
 index: 3
-class_based_api: true
 ---
 
 Input object types are complex inputs for GraphQL operations. They're great for fields that need a lot of structured input, like mutations or search fields. In a GraphQL request, it might look like this:
diff --git a/guides/type_definitions/interfaces.md b/guides/type_definitions/interfaces.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Interfaces
 desc: Interfaces are lists of fields which objects may implement
 index: 4
-class_based_api: true
 redirect_from:
   - /types/abstract_types/
 ---
diff --git a/guides/type_definitions/lists.md b/guides/type_definitions/lists.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Lists
 desc: Ordered lists containing other types
 index: 6
-class_based_api: true
 ---
 
 GraphQL has _list types_ which are ordered lists containing items of other types. The following examples use the [GraphQL Schema Definition Language](https://graphql.org/learn/schema/#type-language) (SDL).
diff --git a/guides/type_definitions/non_nulls.md b/guides/type_definitions/non_nulls.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Non-Null Types
 desc: Values which must be present
 index: 7
-class_based_api: true
 ---
 
 GraphQL's concept of _non-null_ is expressed in the [Schema Definition Language](https://graphql.org/learn/schema/#type-language) (SDL) with `!`, for example:
diff --git a/guides/type_definitions/objects.md b/guides/type_definitions/objects.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Objects
 desc: Objects expose data and link to other objects
 index: 0
-class_based_api: true
 ---
 
 GraphQL object types are the bread and butter of GraphQL APIs. Each object has _fields_ which expose data and may be queried by name. For example, we can query a `User` like this:
diff --git a/guides/type_definitions/scalars.md b/guides/type_definitions/scalars.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Scalars
 desc: Scalars are "simple" data types like integers and strings
 index: 1
-class_based_api: true
 ---
 
 Scalars are "leaf" values in GraphQL. There are several built-in scalars, and you can define custom scalars, too. ({% internal_link "Enums", "/type_definitions/enums" %} are also leaf values.) The built-in scalars are:
diff --git a/guides/type_definitions/unions.md b/guides/type_definitions/unions.md
@@ -6,7 +6,6 @@ section: Type Definitions
 title: Unions
 desc: Unions are sets of types which may appear in the same place (but don't share fields).
 index: 5
-class_based_api: true
 ---
 
 A union type is a set of object types which may appear in the same spot. Here's a union, expressed in [GraphQL Schema Definition Language](https://graphql.org/learn/schema/#type-language) (SDL):
