Repository: phoenixframework/phoenix
Pull request #2474 (2017-09-06 00:38:42)

datastructure -> data structure


Patch:
diff --git a/installer/templates/phx_assets/app.css b/installer/templates/phx_assets/app.css
index 5314c34d2..21d59de1d 100644
--- a/installer/templates/phx_assets/app.css
+++ b/installer/templates/phx_assets/app.css
@@ -1,1 +1,1 @@
-/* This file is for your main application css. */
\ No newline at end of file
+/* This file is for your main application css. */
diff --git a/installer/templates/phx_assets/bare/app.js b/installer/templates/phx_assets/bare/app.js
index 57999a4d9..05738f458 100644
--- a/installer/templates/phx_assets/bare/app.js
+++ b/installer/templates/phx_assets/bare/app.js
@@ -1,3 +1,3 @@
 // for phoenix_html support, including form and button helpers
 // copy the following scripts into your javascript bundle:
-// * https://raw.githubusercontent.com/phoenixframework/phoenix_html/v2.10.0/priv/static/phoenix_html.js
\ No newline at end of file
+// * https://raw.githubusercontent.com/phoenixframework/phoenix_html/v2.10.0/priv/static/phoenix_html.js
diff --git a/lib/phoenix/controller.ex b/lib/phoenix/controller.ex
index 204d94773..5917a2db6 100644
--- a/lib/phoenix/controller.ex
+++ b/lib/phoenix/controller.ex
@@ -203,7 +203,7 @@ defmodule Phoenix.Controller do
   the render block and instead return the unmatched value. In this case,
   imagine `Blog.fetch_post/2` returned `{:error, :not_found}` or
   `Authorizer.authorize/3` returned `{:error, :unauthorized}`. For cases
-  where these datastructures serve as return values across multiple
+  where these data structures serve as return values across multiple
   boundaries in our domain, a single fallback module can be used to
   translate the value into a valid response. For example, you could
   write the following fallback controller to handle the above values:
diff --git a/lib/phoenix/presence.ex b/lib/phoenix/presence.ex
index 5956aafa4..da4553306 100644
--- a/lib/phoenix/presence.ex
+++ b/lib/phoenix/presence.ex
@@ -55,8 +55,8 @@ defmodule Phoenix.Presence do
   the socket's topic is pushed to the client as a `"presence_state"` event.
   Next, `Presence.track` is used to register this
   channel's process as a presence for the socket's user ID, with
-  a map of metadata. 
-  
+  a map of metadata.
+
   Finally, a diff of presence join and leave events will be sent to the
   client as they happen in real-time with the "presence_diff" event.
   The diff structure will be a map of `:joins` and `:leaves` of the form:
@@ -65,7 +65,7 @@ defmodule Phoenix.Presence do
         leaves: %{"456" => %{metas: [%{status: "online", phx_ref: ...}]},
 
   See `Phoenix.Presence.list/2` for more information on the presence
-  datastructure.
+  data structure.
 
   ## Fetching Presence Information
 
@@ -78,7 +78,7 @@ defmodule Phoenix.Presence do
   before broadcasting the information to all channel subscribers.
   This prevents N query problems and gives you a single place to group
   isolated data fetching to extend presence metadata. The function must
-  return a map of data matching the outlined Presence datastructure,
+  return a map of data matching the outlined Presence data structure,
   including the `:metas` key, but can extend the map of information
   to include any additional information. For example:
 
@@ -208,7 +208,7 @@ defmodule Phoenix.Presence do
   @doc """
   Returns presences for a topic.
 
-  ## Presence datastructure
+  ## Presence data structure
 
   The presence information is returned as a map with presences grouped
   by key, cast as a string, and accumulated metadata, with the following form:
diff --git a/priv/templates/phx.gen.context/access_no_schema.ex b/priv/templates/phx.gen.context/access_no_schema.ex
index b23ed44bf..104175d62 100644
--- a/priv/templates/phx.gen.context/access_no_schema.ex
+++ b/priv/templates/phx.gen.context/access_no_schema.ex
@@ -76,7 +76,7 @@
   end
 
   @doc """
-  Returns a datastructure for tracking <%= schema.singular %> changes.
+  Returns a data structure for tracking <%= schema.singular %> changes.
 
   ## Examples
 
diff --git a/priv/templates/phx.gen.presence/presence.ex b/priv/templates/phx.gen.presence/presence.ex
index e86438c79..387461f0d 100644
--- a/priv/templates/phx.gen.presence/presence.ex
+++ b/priv/templates/phx.gen.presence/presence.ex
@@ -34,7 +34,7 @@ defmodule <%= module %> do
 
   Finally, a diff of presence join and leave events will be sent to the
   client as they happen in real-time with the "presence_diff" event.
-  See `Phoenix.Presence.list/2` for details on the presence datastructure.
+  See `Phoenix.Presence.list/2` for details on the presence data structure.
 
   ## Fetching Presence Information
 
@@ -45,7 +45,7 @@ defmodule <%= module %> do
   isolated data fetching to extend presence metadata.
 
   The function receives a topic and map of presences and must return a
-  map of data matching the Presence datastructure:
+  map of data matching the Presence data structure:
 
       %{"123" => %{metas: [%{status: "away", phx_ref: ...}],
         "456" => %{metas: [%{status: "online", phx_ref: ...}]}


Test patch:
diff --git a/installer/templates/phx_test/support/channel_case.ex b/installer/templates/phx_test/support/channel_case.ex
index 2e90df4c1..9031b01e3 100644
--- a/installer/templates/phx_test/support/channel_case.ex
+++ b/installer/templates/phx_test/support/channel_case.ex
@@ -5,7 +5,7 @@ defmodule <%= web_namespace %>.ChannelCase do
 
   Such tests rely on `Phoenix.ChannelTest` and also
   import other functionality to make it easier
-  to build common datastructures and query the data layer.
+  to build common data structures and query the data layer.
 
   Finally, if the test case interacts with the database,
   it cannot be async. For this reason, every test runs
diff --git a/installer/templates/phx_test/support/conn_case.ex b/installer/templates/phx_test/support/conn_case.ex
index b6611808e..f5e774b7c 100644
--- a/installer/templates/phx_test/support/conn_case.ex
+++ b/installer/templates/phx_test/support/conn_case.ex
@@ -5,7 +5,7 @@ defmodule <%= web_namespace %>.ConnCase do
 
   Such tests rely on `Phoenix.ConnTest` and also
   import other functionality to make it easier
-  to build common datastructures and query the data layer.
+  to build common data structures and query the data layer.
 
   Finally, if the test case interacts with the database,
   it cannot be async. For this reason, every test runs