Skip to content

Conversation

NullVoxPopuli
Copy link
Contributor

@NullVoxPopuli NullVoxPopuli commented Oct 3, 2023

Supersedes?: #709


The existing load function/helper combo gets the job done, but this new component has a similar top-level API but requires no if-based branching. Instead, it uses named blocks to render the resulting state.

import { Async } from 'ember-async-data';

<template>
  <Async @data={{Promise.resolve 123}}>
    <:pending>Still waiting...</:pending>
    <:resolved as |value|>
      The value is: {{value}}.
    </:resolved>
    <:rejected>Whoops! Something went wrong!</:rejected>
  </Async>
</template>

This ends up being both briefer and less error prone, not least since it provides the resolved value automatically from the resolved block, whereas expressly checking {{#if someAsyncData.isResolved}} allowed the further {{someAsyncData.value}} access but did not provide it automatically.

chriskrycho and others added 2 commits October 3, 2023 15:12
The existing `load` function/helper combo gets the job done, but this
new component has a similar top-level API but requires no `if`-based
branching. Instead, it uses named blocks to render the resulting state.

    import { Async } from 'ember-async-data';

    <template>
      <Async @DaTa={{Promise.resolve 123}}>
        <:pending>Still waiting...</:pending>
        <:resolved as |value|>
          The value is: {{value}}.
        </:resolved>
        <:rejected>Whoops! Something went wrong!</:rejected>
      </Async>
    </template>

This ends up being both briefer *and* less error prone, not least since
it provides the resolved value automatically from the `resolved` block,
whereas expressly checking `{{#if someAsyncData.isResolved}}` *allowed*
the further `{{someAsyncData.value}}` access but did not provide it
automatically.
…ompatible with the template-tag plugin, and prettier@v3 is not compatible with the current version of eslint/stylelint configs (we could do further upgrades tho, but this is what we want in the long run anyway)
@SergeAstapov
Copy link
Collaborator

@NullVoxPopuli do you think we could split infra updates into separate PR to keep this managed/focused?
Also I think .gts conversion for existing tests could be separate PR, e.g. I was doing this as well in #688

@NullVoxPopuli
Copy link
Contributor Author

@NullVoxPopuli do you think we could split infra updates into separate PR to keep this managed/focused?

Yes, this makes sense -- usually my way of working is to spike all the way to the end / green (so that I know my direction is even valid), and then pull the isolated stuff out.

Also I think .gts conversion for existing tests could be separate PR, e.g. I was doing this as well in #688

ah awesome! I'll rebase once that's merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants