Replace remaining AJAX -> Ajax

sfcasts/ep1/async-computed.md

@@ -19,7 +19,7 @@ search query and get a sub-set of results.
 ## Adding Search to the Product Service
 
 Back in our code, open up `services/products-service.js`. This function is
-responsible for making the AJAX request for products and it can already filter by
+responsible for making the Ajax request for products and it can already filter by
 category. Now, add a *second* argument called `searchTerm`. Then, very simply,
 if we have a `searchTerm`, say `params.name = searchTerm` to add the query parameter.
 I'll even document the new param: it  will be a `string` or `null` and it's
@@ -29,7 +29,7 @@ called `searchTerm`.
 
 Very nice!
 
-## AJAX inside a Computed Property?
+## Ajax inside a Computed Property?
 
 Let's use this in `catalog.vue`. I'm going to do this in the *simplest* way
 possible first... and it's totally *not* going to work! We currently have a
@@ -50,7 +50,7 @@ Much better! To finish the function, I'll go steal some more code and say
 [[[ code('72cfdccf60') ]]]
 
 So... this makes sense, right? When we reference `filteredProducts` in the template,
-that will call our function, we make the AJAX call, wait for it to finish
+that will call our function, we make the Ajax call, wait for it to finish
 and then return the new array of products. Genius!
 
 But... you can already see that we have an angry underline below `await`.
@@ -81,13 +81,13 @@ but are "boo!" for async stuff.
 The solution is to abandon your project and take up a peaceful career herding
 sheep. *Or*, you'll need to convert the computed property into a piece of data.
 And then, whenever that data needs to change - like whenever the `searchTerm`
-changes - you'll call a method that will *make* the AJAX call
+changes - you'll call a method that will *make* the Ajax call
 and *update* that data once its done.
 
 So... let's do this! The first step is to add a piece of data that can hold the
 filtered products. But, actually, now that we're not trying to keep *all* the
 products in the `products` data so that we can filter based off of it, whenever our
-AJAX call finishes, it's now ok to *change* that `products` array directly.
+Ajax call finishes, it's now ok to *change* that `products` array directly.
 So instead of adding a *new* piece of data - we'll just change products.
 
 Sweet! This means that, up in the template, we should change `filteredProducts`
@@ -98,7 +98,7 @@ back to `products`. And back down, we can remove the computed section entirely.
 ## Updating products on searchTerm Change
 
 Here's the plan then: whenever the `searchTerm` changes, we basically want to
-re-run all of the code that makes the AJAX call and updates the `products` data...
+re-run all of the code that makes the Ajax call and updates the `products` data...
 but with a minor addition to *also* include the search query.
 
 To help re-use this, create a new method called `loadProducts()` with a
@@ -127,7 +127,7 @@ Add `this.loadProducts()` and pass `event.term`.
 
 [[[ code('fe215217d1') ]]]
 
-Thanks to this, when `onSearchProducts()` is called, this will *start* the AJAX
+Thanks to this, when `onSearchProducts()` is called, this will *start* the Ajax
 call. Later, when it finishes, the `products` data will get updated and the component
 will re-render.
 
@@ -139,7 +139,7 @@ So celebrate by removing the `searchTerm` data.
 
 Moment of truth! Let's refresh the page to be safe and... type. Yes! This
 matches 2 products and `disk` matches one. In Symfony's web debug toolbar, you
-can see the AJAX calls. We now have the ability to make our search as *powerful*
+can see the Ajax calls. We now have the ability to make our search as *powerful*
 as our heart desires.
 
 ## Destructured Event Arg
@@ -157,7 +157,7 @@ string. Extra credit if you describe the function above.
 [[[ code('011fe3787c') ]]]
 
 After this change... the search still works. But... wow! This is making a *lot*
-of AJAX calls! Even if we type *really* fast, it makes one AJAX call per letter!
+of Ajax calls! Even if we type *really* fast, it makes one Ajax call per letter!
 Let's fix that next by adding debouncing.
 
 Oh, but before we do, it's not hurting anything, but since the `created()`

sfcasts/ep1/await.md

@@ -1,6 +1,6 @@
 # The await Keyword
 
-Before we start using the products data from the AJAX call, there's *one* other
+Before we start using the products data from the Ajax call, there's *one* other
 way to work with promises... and I really like it! It's the `await` syntax. We
 know that Axios returns a Promise... and that we *normally* run code *after* a
 promise has finished - or "resolved" - by calling `.then()` on it.
@@ -12,7 +12,7 @@ If we stopped right now, response would actually be a *Promise* - not a response
 But if we put `await` in front of it, it *will* be a response! The `await`
 keyword causes your code to *wait* for that Promise to resolve. And whatever data
 is *normally* passed to your callback as an argument is instead *returned*. There
-is *still* an asynchronous AJAX call happening, but our code *reads* a bit more like
+is *still* an asynchronous Ajax call happening, but our code *reads* a bit more like
 synchronous code. The `await` keyword is syntactic sugar.
 
 [[[ code('463cdb202c') ]]]
@@ -41,15 +41,15 @@ automatically and *always* return a `Promise`. If your function has a `return` v
 that will be the *data* of the Promise.
 
 This... can be confusing at first: when `mounted()` is called, our code *will*
-freeze on the `async` line and wait for the AJAX call to finish. But this doesn't
+freeze on the `async` line and wait for the Ajax call to finish. But this doesn't
 freeze our entire JavaScript app. In reality, the `mounted()` function will almost
 *immediately* finish and will return a Promise. That Promise will *resolve* once
 all of our code executes.
 
 To say this a different way: if *we* called `mounted()` directly from our code -
 we won't do that, but just pretend - then `mounted()` would finish before the
-AJAX call and it would *now* return a Promise. If we wanted to do something
-*after* the AJAX call and the rest of the code in `mounted()` finished, we could
+Ajax call and it would *now* return a Promise. If we wanted to do something
+*after* the Ajax call and the rest of the code in `mounted()` finished, we could
 chain a `.then()` *from* that Promise.
 
 But in reality, *Vue* is responsible for calling `mounted()` and Vue doesn't
@@ -60,9 +60,9 @@ method to return a Promise.
 The key thing to know about `async` and `await` is that even though our code will
 wait on this line, *really* the `mounted()` function will finish nearly instantly.
 Vue isn't going to call `mounted()` then freeze our *entire* Vue app waiting for
-it to finish. It starts our AJAX call then keeps going. That's *perfect*.
+it to finish. It starts our Ajax call then keeps going. That's *perfect*.
 
-Anyways, now when we refresh... yes! The AJAX call finishes and logs the response.
+Anyways, now when we refresh... yes! The Ajax call finishes and logs the response.
 Feel free to use Promises directly or with `await`: we'll use `await` in this tutorial.
 
 ## Adding the products Data & hydra:member

sfcasts/ep1/debounce.md

@@ -1,11 +1,11 @@
 # Debouncing: Data can Hold Anything
 
 The only problem is that we made our search *too* awesome. When I type...
-wow! Look at those are AJAX requests - one for *every* character I type. It's,
+wow! Look at those are Ajax requests - one for *every* character I type. It's,
 sort of unnecessarily flooding our API.
 
 This is a common problem with a common solution: debouncing, which is *almost*
-as fun as it sounds. With debouncing, instead of sending an AJAX request after
+as fun as it sounds. With debouncing, instead of sending an Ajax request after
 *every* letter, we wait until the user *stops* typing - maybe 200 milliseconds -
 and *then* make the request.
 
@@ -28,7 +28,7 @@ Easy peasy! Oh, and the arrow function is important: if we used a traditional
 function, the `this` variable wouldn't be our Vue instance. Silly JavaScript!
 
 Now, some of you probably realize that this isn't going to *quite* work yet.
-If we refresh... and then type really fast. Ah! It *still* sent four AJAX
+If we refresh... and then type really fast. Ah! It *still* sent four Ajax
 requests... it just waited 200 milliseconds before making each of them. Whoops!
 
 ## Storing and Clearing the Timeout
@@ -63,7 +63,7 @@ can reset the `searchTimeout` back to null.
 Now, if we type really fast, the second time `onInput()` is called, it will
 *clear* the timeout, and then, below, start a *new* one.
 
-Let's try it! I'll refresh to be sure then... type super fast. Yes! Just one AJAX
+Let's try it! I'll refresh to be sure then... type super fast. Yes! Just one Ajax
 call down here to the categories API. That's *beautiful*!
 
 ## Non-Reactive Stuff on Data?

sfcasts/ep1/dev-server.md

@@ -68,13 +68,13 @@ the changes.
 ## dev-server & HTTPS
 
 But... the dev-server opens up some interesting possibilities. First, you might
-notice that a bunch of AJAX requests are failing on this page. It's some
+notice that a bunch of Ajax requests are failing on this page. It's some
 `sockjs-node` thing from that dev server. One of the super powers of the dev
 server is that it can automatically update the JavaScript and CSS in your browser
 *without* you needing to reload the page. To do that, it makes a connection back
 to the dev-server to look for changes.
 
-This if failing because it's trying to use https for the AJAX call and, unless
+This if failing because it's trying to use https for the Ajax call and, unless
 you configure it, the dev-server only works for http. And it's trying to use https
 because *our* page is running on https.
 
@@ -95,7 +95,7 @@ access your site with http so that this request *also* uses http.
 When we originally started the Symfony web server, we started it
 with `symfony serve -d` and then `--allow-http`. This means that the web server
 supports https, but we're *allowed* to use http. Once we change to http in the
-URL... the AJAX call starts working!
+URL... the Ajax call starts working!
 
 If you have a more complex setup, like you need to change the host name or have
 CORS issues, check out the Encore dev-server docs or drop us a question in the

sfcasts/ep1/filter-products.md

@@ -22,7 +22,7 @@ Head back to our app. From the top level `products.vue`, hold Command or Ctrl an
 click `<catalog />` to jump into that component. Catalog is responsible
 for loading our products on `created` by making a request to `/api/products`. Hmm...
 I *wish* we had access to the `currentCategoryId` here... because we could use
-that to change the URL in the AJAX call! Well then... let's go get it!
+that to change the URL in the Ajax call! Well then... let's go get it!
 
 Back in `products.vue`, add `:current-category-id="currentCategoryId"` to pass it
 as a prop... *just* like we did with the sidebar.
@@ -34,7 +34,7 @@ definition from sidebar - it's perfect there - and paste it here.
 
 [[[ code('a54515f596') ]]]
 
-## Using currentCategoryId to Filter on the AJAX call
+## Using currentCategoryId to Filter on the Ajax call
 
 Wonderful! We are *now* receiving `currentCategoryId`. To use this, down in
 `created` we *could* add `?category=` and then the `currentCategoryId`. But with
@@ -76,5 +76,5 @@ That's... my fault. When `catalog` renders `product-list` - hold Command or Ctrl
 click to jump to that - the loading is showing based on whether the `products`
 length is zero or not. An empty category *looks* like it's still loading!
 
-We *need* to improve this: we need to *truly* know whether or not the AJAX call
+We *need* to improve this: we need to *truly* know whether or not the Ajax call
 has finished! Let's make a *smarter* loading mechanism next!

sfcasts/ep1/filtering-products.md

@@ -70,4 +70,4 @@ list? Or maybe we have a super-cool Elasticsearch system that we want to use?
 
 The point is: filtering on the client-side *might* work in some simple cases...
 but most of the time, you'll probably want to perform a search on the server via
-an AJAX call. Let's do that next!
+an Ajax call. Let's do that next!

sfcasts/ep1/helpers.md

@@ -3,7 +3,7 @@
 We've already been organizing our code in several ways. The biggest way
 is that we've been breaking our components down into smaller pieces, which is
 *awesome*! We also created services for fetching data, whether that's via
-AJAX calls or by grabbing a global variable.
+Ajax calls or by grabbing a global variable.
 
 But these aren't the only ways we can organize our code. In
 JavaScript, like with most languages, if you have a chunk of code that's

sfcasts/ep1/hoist-data.md

@@ -1,12 +1,12 @@
 # Hoisting Data Up
 
 We just discussed that, because the `categories` in our app are static - we
-don't load them with AJAX and they never change - they don't *really* need to live
+don't load them with Ajax and they never change - they don't *really* need to live
 as data on a component and it would be *totally* ok to fetch them directly - wherever
 we need them - from `categories-service`.
 
 But... we're going to take the more complex path by pretending that our categories
-*are* still loading via AJAX... which means they *do* change during the lifecycle
+*are* still loading via Ajax... which means they *do* change during the lifecycle
 of our app... which means that they *do* need to live as data on a component.
 
 ## Computed property for Category Name
@@ -33,7 +33,7 @@ The `find()` function *effectively* loops over all the categories, calls this
 function for each one, and returns the first that makes this expression true.
 
 At the bottom, add `return` and use the ternary syntax: if a category was found,
-which... it should be unless the `categories` data is loading via AJAX and is
+which... it should be unless the `categories` data is loading via Ajax and is
 empty at first - then return `category.name`. Else, use an empty string...
 or you could say "Loading...".
 

sfcasts/ep1/loading.md

@@ -20,7 +20,7 @@ your component is completely removed.
 
 ## mounted vs created
 
-We used `mounted` earlier to start our AJAX call. That means that our Vue instance
+We used `mounted` earlier to start our Ajax call. That means that our Vue instance
 was created, mounted into the DOM, and *then* the function was called. It turns
 out that a better place to load data is actually `created`.
 
@@ -30,7 +30,7 @@ That works *just* fine.
 [[[ code('63e5042dc0') ]]]
 
 The `created()` function is called as *soon* as the Vue instance for our component
-is instantiated. That lets us start our AJAX call as *early* as possible. By the
+is instantiated. That lets us start our Ajax call as *early* as possible. By the
 time it's mounted onto the page, the `products` data may or may *not* yet be available,
 probably they aren't. But it doesn't really matter. And we can see this when we
 refresh: the products are *missing* for a moment.
@@ -96,7 +96,7 @@ We're not *conditionally* hiding and showing that yet but... there it is! Not ba
 
 ## Hiding / Showing the Loading Animation
 
-Ok: we only want to show the `Loading` component when the products AJAX
+Ok: we only want to show the `Loading` component when the products Ajax
 call hasn't finished. The two different ways to conditionally hide or show something
 are `v-show` and `v-if`. In this case, especially because we're *eventually* going
 to be loading the product list multiple times when we have a search bar, let's use
@@ -113,7 +113,7 @@ We can also add a `v-show=""` on the `product-card` element with
 `products.length > 0`. It's not *really* needed since this won't even loop if there
 are no products, but it balances things.
 
-We now have dynamic products *and* a loading animation while the AJAX call is
+We now have dynamic products *and* a loading animation while the Ajax call is
 finishing. I'm super happy about that! But our categories are *not* dynamic yet.
 Wah, wah. Let's fix that next. But after we do, we'll explore a *faster* way to
 load them.

sfcasts/ep1/page-service.md

@@ -6,7 +6,7 @@ to our front-end app. But global variables are still global variables and we
 should *try* to *at least* isolate and organize them as much as possible. Because,
 for example, what if we changed our app to use the Vue router? Instead of full
 page refreshes where we set the `currentCategoryId` as a global variable in Twig,
-*now* that data would be returned in a *different* way: via an AJAX call.
+*now* that data would be returned in a *different* way: via an Ajax call.
 
 The point is: the way we get `currentCategoryId` could change. And if we have
 `window.currentCategoryId` sprinkled around our code everywhere, it's... not ideal.
@@ -18,7 +18,7 @@ JavaScript services!
 I think you're *really* going to like this. Inside my `js/` directory, create
 a new folder called `services/`. So far, everything we've worked on has been
 Vue components... but there's a lot more to our app. We have code for making
-AJAX calls - which we will eventually centralize - and we're also going to have
+Ajax calls - which we will eventually centralize - and we're also going to have
 generic logic that we want to reuse from multiple places.
 
 In our app, the `services/` directory is going to hold files that help us

sfcasts/ep1/product-card.md

@@ -113,7 +113,7 @@ earlier: the fact that we kept the `products` data inside `catalog.vue` even
 though the `product-list` component is *technically* the deepest component that
 needs it.
 
-If you look at `catalog.vue`, it holds the AJAX call and pretty soon it will
+If you look at `catalog.vue`, it holds the Ajax call and pretty soon it will
 hold logic for a search bar. But... it doesn't render a lot of markup. I mean,
 yeah, it has an `<h1>` up here and a `<div>` down here, but its *main* job is
 to contain data and logic.
@@ -126,7 +126,7 @@ that's often followed in Vue and React. It's called smart versus dumb components
 or container versus presentational components.
 
 This pattern says that you should try to organize some components to be smart -
-components that make AJAX calls and change state - and other components to be
+components that make Ajax calls and change state - and other components to be
 dumb - that receive props, render HTML and maybe emit an event when the user does
 something.
 
@@ -146,6 +146,6 @@ obsess over it. We're doing a good job of making this separation in some places,
 but we're not perfect either, and I think that's great. However, if you can
 *generally* follow this, you'll be happier with your components.
 
-Next, now that we're loading data via AJAX, we need a way to tell the *user*
+Next, now that we're loading data via Ajax, we need a way to tell the *user*
 that things are loading... not that our server is on fire and they're waiting for
 nothing. Let's create a Loading component that we can re-use anywhere.

sfcasts/ep1/props-vs-service.md

@@ -114,6 +114,6 @@ to pass it down as props. If we want to, it would be *totally* ok fetch the
 categories directly from `categories-service` wherever we need it.
 
 Now that you know the *easy* solution, let's take the *harder* path. Let's pretend
-that our categories *are* still loading via AJAX... which means that *technically*
+that our categories *are* still loading via Ajax... which means that *technically*
 they *do* change during our app's lifecycle: they're empty for a moment, and
 *then* they populate. Let's tackle this next.