Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: fix typos and inconsistencies #944

Merged
merged 1 commit into from
Jul 13, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions docs/docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ In Starbeam,

And Starbeam is planned for inclusion in the next [edition](https://emberjs.com/editions/) of Ember, Polaris.

It's no secret that Ember's community is smaller other javascript communities, so one of the goals of Polaris is to reduce the amount of maintenance that small community needs to do. For example, the [embroider](https://github.com/embroider-build/embroider/) project aims to reduce the maintenance burden on the build system by using broader ecosystem tools such as webpack, vite, rollup, etc. Another example is the reactivity system, `@glimmer/tracking`. We don't need it to be specific to Ember, and in fact, the Starbeam project _is that_ -- Ember's Reactivity _for everyone_, and has focused on [`React`](https://www.starbeamjs.com/frameworks/react/) and [`Preact`](https://www.starbeamjs.com/frameworks/preact/) first, with [`Vue`](https://github.com/starbeamjs/starbeam/tree/main/packages) shortly behind. Reactivity is a non-trivial system that, with bigger community, can help lighten the load on ember maintainers, and additionally breathe new life (and performance) in to the framework by providing reactive primitives at a much lower layer in the tech stack.
It's no secret that Ember's community is smaller than other javascript communities, so one of the goals of Polaris is to reduce the amount of maintenance that a small community needs to do. For example, the [embroider](https://github.com/embroider-build/embroider/) project aims to reduce the maintenance burden on the build system by using broader ecosystem tools such as webpack, vite, rollup, etc. Another example is the reactivity system, `@glimmer/tracking`. We don't need it to be specific to Ember, and in fact, the Starbeam project _is that_ -- Ember's Reactivity _for everyone_, and has focused on [`React`](https://www.starbeamjs.com/frameworks/react/) and [`Preact`](https://www.starbeamjs.com/frameworks/preact/) first, with [`Vue`](https://github.com/starbeamjs/starbeam/tree/main/packages) shortly behind. Reactivity is a non-trivial system that, with bigger community, can help lighten the load on ember maintainers, and additionally breathe new life (and performance) in to the framework by providing reactive primitives at a much lower layer in the tech stack.

<details><summary>Additional Starbeam primitives</summary>

Expand Down Expand Up @@ -195,7 +195,7 @@ function shout(text) {
```
It's _just a function_. And we don't like to use the word "just" in technical writing, but there are honestly 0 caveats or gotchyas here.

Used in Ember, it make look like this:
Used in Ember, it may look like this:
```js
function shout(text) {
return text.toUpperCase();
Expand Down Expand Up @@ -237,7 +237,7 @@ setTimeout(() => {
_Why does cleanup matter?_

Many things in a JavaScript app require cleanup. We need to cleanup in order to:
- prevent to memory leaks
- prevent memory leaks
- reduce unneeded network activity
- reduce CPU usage

Expand All @@ -252,7 +252,7 @@ _Resources_ are functions with cleanup, but cleanup isn't all they're conceptual
> That allows you to work with a process just like you'd work with any other reactive value.
>

For details on resources, see [./resources.md](./resources.md).
For details on resources, see the [Resources chapter](./resources.md).

Here is an interactive demo showcasing how [resources are reactive functions with cleanup](https://tutorial.glimdown.com/2-reactivity/5-resources)

Expand Down
24 changes: 12 additions & 12 deletions docs/docs/ember.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,9 @@
2. [Resources](./resources.md)
3. [Usage in Ember](./ember.md) 👈 You are here

`ember-resources` tries to stay out of your way when working with Resources.
`ember-resources` tries to stay out of your way when working with resources.

This document shows the mechanics of how to interact with a Resource in ember.
This document shows the mechanics of how to interact with a resource in ember.

## Direct usage in template

Expand Down Expand Up @@ -41,16 +41,16 @@ const Clock = resourceFactory((locale) => {

### In Templates

In `ember-resources`, Resources are powered by Ember's "Helper Manager" APIs, such as [`invokeHelper`](https://api.emberjs.com/ember/release/functions/@ember%2Fhelper/invokeHelper).
In `ember-resources`, resources are powered by Ember's "Helper Manager" APIs, such as [`invokeHelper`](https://api.emberjs.com/ember/release/functions/@ember%2Fhelper/invokeHelper).

So in order to use Resources in template-only components, they'll need to be re-exported in your `app/helpers/*` folder.
So in order to use resources in template-only components, they'll need to be re-exported in your `app/helpers/*` folder.

For example, by defining `app/helpers/clock.js`,
```js
export { Clock as default } from './location/of/clock';
```

you'd then be able to directly reference `Clock` in your template, albeit in the lower-kebab-case format (i.e.: if your helper is MultiWard, it's invoked as `multi-word`),
you'd then be able to directly reference `Clock` in your template, albeit in the lower-kebab-case format (i.e.: if your helper is MultiWord, it's invoked as `multi-word`),

```hbs
{{ (clock) }}
Expand All @@ -59,7 +59,7 @@ you'd then be able to directly reference `Clock` in your template, albeit in the

### When the template has a backing class.

Because resources in `ember-resources` are backed by the Helper Manager API, and ever since "everything that has a value can be used in a template" [docs here](https://guides.emberjs.com/release/in-depth-topics/rendering-values/), we can _almost_ use Resources in templates _as if_ you were using `<template>`.
Because resources in `ember-resources` are backed by the Helper Manager API, and ever since "everything that has a value can be used in a template" [docs here](https://guides.emberjs.com/release/in-depth-topics/rendering-values/), we can _almost_ use resources in templates _as if_ you were using `<template>`.
This is not a feature of ember-resources, but it is a useful technique that we've been able to use since `ember-source@3.25`

```js
Expand Down Expand Up @@ -155,11 +155,11 @@ work as you'd expect:
```js

import { use } from 'ember-resources';
import { Clock } from './location/of/clock';
import { Clock, ClockWithArgs } from './location/of/clock';

class Demo {
@use(Clock) clock;
@use(ClockWithArg('en-US')) clock;
@use(ClockWithArgs('en-US')) clockWithArg;
}
```

Expand Down Expand Up @@ -312,11 +312,11 @@ and each of the individual `{{ }}` usages will individually auto-track with the

### Typing the above examples

If you've used typescript in ember before, this may look familiar as we declare the types on services in the same way. This follows the same pattern described [here](https://jamescdavis.com/declare-your-injections-or-risk-losing-them/)
If you've used TypeScript in Ember before, this may look familiar as we declare the types on services in the same way. This follows the same pattern described [here](https://jamescdavis.com/declare-your-injections-or-risk-losing-them/)

```ts
import { use } from 'ember-resources';
import { Clock } from './location/of/clock';
import { Clock, ClockWithArgs } from './location/of/clock';

class Demo {
clock = use(this, Clock);
Expand All @@ -330,7 +330,7 @@ class Demo {
```ts
import { use } from 'ember-resources';
import { tracked } from '@glimmer/tracking';
import { Clock } from './location/of/clock';
import { Clock, ClockWithReactiveArgs } from './location/of/clock';

class Demo {
@tracked locale = 'en-US';
Expand All @@ -343,7 +343,7 @@ class Demo {

### For Library Authors

For TypeScript, you may have noticed that, if you're a library author, you may want to be concerned with supporting all usages of Resources in all contexts, in which case, you may need to support overloaded function calls.
For TypeScript, you may have noticed that, if you're a library author, you may want to be concerned with supporting all usages of resources in all contexts, in which case, you may need to support overloaded function calls.

TypeScript does not support overloading anonymous functions, so we need to abstract the callback passed to `resourceFactory` into a named function, which we can then define overloads for.

Expand Down