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

[Umbrella] Releasing Suspense #13206

Open
acdlite opened this issue Jul 13, 2018 · 64 comments

Comments

@acdlite
Copy link
Member

commented Jul 13, 2018

Let's use this issue to track the remaining tasks for releasing Suspense to open source.

Initial release (MVP)

Core

  • API to read context from within any render phase function (@acdlite) [#13139]
  • Hide timed-out content instead of deleting it (@acdlite) [#13120]
  • Automatic injection of context providers per React root (@acdlite) [#13293]
  • Remove unstable_ prefix from AsyncMode (maybe?)
  • Support for synchronous thenables, and for promises that resolve before the render phase is complete.
    • Confirm that a synchronous thenable that throws an error is handled correctly
  • Confirm it works with <div hidden> [#13089]
  • Why does clicking on several detail links in the fixture one by one eventually causes a big placeholder even if I wait for each of them for less than the placeholder delay before clicking the next one (see tweet)?

Simple Cache Provider

Code splitting

  • Support promise as a component type
  • (maybe) Open source lazyLoadComponent?

Test renderer

  • Finalize public APIs for flushAll, yield, etc
    • Tentative plan is to publish custom matchers for each of the major testing frameworks, a la #13236.

Docs

  • Blog post
  • React.Placeholder
  • simple-cache-provider
  • Unnamed code-splitting library

Follow ups

Soft expiration (#14248)

  • Implement an API for in-place loading indicators that aren't ancestors
  • Make sure there's a way to avoid flashing the inline spinner if it's fast enough

Streaming server renderer

  • Implement a streaming server renderer like the one in @acdlite's ZEIT talk
  • Partial hydration

Related: Time Slicing Umbrella (#13306)

@aweary

This comment has been minimized.

Copy link
Member

commented Jul 13, 2018

Expose unstable_AsyncMode (maybe?)

Isn't this already exposed?

@acdlite

This comment has been minimized.

Copy link
Member Author

commented Jul 13, 2018

I meant remove the unstable_

@thoamsy

This comment has been minimized.

Copy link

commented Jul 15, 2018

I am looking forward to open source of the unnamed code-splitting library 💯

@ryota-murakami

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2018

What does it mean [Umbrella]?🤔☂️

@ghoullier

This comment has been minimized.

Copy link

commented Jul 23, 2018

This mean, it's a feature which impact several projects/packages/tools.

@ryota-murakami

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2018

@ghoullier I see, Thank you so much!

@JedWatson

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2018

Hey @acdlite, just a question about how to best prepare for this. Not asking for / expecting any kind of timeline, but wondering:

Are you currently expecting these features to drop into React 16 and be easy to adopt incrementally, like the new Context API that landed with 16.3?

Or are you thinking it'll be something that pushes React to v17 and require more work to adopt?

Asking because I'm working on a roadmap that crosses over significantly with pretty much everything on your list and am trying to work out how to best deal with that.

Also do you have any tips on how to best prepare (in terms of code written today, that wants to be future compatible with these improvements to React) - polyfills / techniques / etc?

(apologies if these questions are answered elsewhere and I've missed them)

@donaldpipowitch

This comment has been minimized.

Copy link

commented Jul 24, 2018

Adding another question to @JedWatson's questions:

  • We also don't need/expect to get a timeline for a stable release, but would it be possible/useful to get a new prerelease? (AFAIK the newest release is 16.4.0-alpha.0911da3 from February.)

Thank you! ❤️

@NE-SmallTown

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2018

IMO, they will provide a blog post like before before it's been landed.

And I think you don't need to prepare too much because there is no breaking change(it does have many features that maybe would seems different/conflict with current practices, like redux fetch with suspense, but there will be a codemod or easy encapsulation to do this, you know, fb has 3W+ components). And if you watch the talk of @acdlite (about ssr suspense in ZEIT) and @gaearon (about client suspense in iceland), you will know you don't need to worry about too much and it's not invasive.

By the way, you can just search the key 'Umbrella' in the repo and you will find more info like #8830 and #12152

AFAIK the newest release is 16.4.0-alpha.0911da3 from February.

IIRC, this is a misoperation?

@sebinsua

This comment has been minimized.

Copy link

commented Jul 24, 2018

@cyan33

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2018

I'm working on rolling out the suspense module and new APIs in facebook. In case @acdlite is busy with something else, I'd like to share some of my thoughts of our experience in facebook and answer some questions of @JedWatson.

Are you currently expecting these features to drop into React 16 and be easy to adopt incrementally, like the new Context API that landed with 16.3?

I'm not sure if it will come with React 16 or 17. According to the React team, it's likely to be released before the end of this year, which depends on how well it runs in facebook and how the related API is ready or not. But code-wise, I'm happy to say that it would be easy to adopt, because we've been experimenting for quite a while in facebook. The suspense feature will still work for the existing codebase. But with additional changes (like async rendering), you'll have more bonus that the new feature will bring you.

Do you have any tips on how to best prepare (in terms of code written today, that wants to be future compatible with these improvements to React) - polyfills / techniques / etc?

I'd say the migration is rather incremental and progressive. Like @NE-SmallTown said, we don't want to introduce any breaking changes. That would also be painful to roll out to facebook because we have a so large codebase. But so far, the roll out has been smooth and doesn't require you to do additional changes.

@acdlite

This comment has been minimized.

Copy link
Member Author

commented Jul 24, 2018

@JedWatson

Are you currently expecting these features to drop into React 16 and be easy to adopt incrementally, like the new Context API that landed with 16.3?

Incrementally. Always incrementally :) Otherwise there's no way we'd be able to ship this at Facebook.

Here's what I'm expecting:

Client Server-side rendering
Suspense Works everywhere* Same constraints as existing server renderer
Async rendering Opt-in using <AsyncMode> Same constraints as existing server renderer

*In sync mode, delayMs is always 0. Placeholders show up immediately.

Suspense will work without any changes to your existing components. At one point we thought we might require <StrictMode> compatibility, but during our internal testing we discovered one of the best ways to upgrade to strict mode was to use Suspense. Chicken-egg dilemma. So we found a way to make it work even outside of strict mode.

So the idea is that users will start migrating to Suspense even before they're ready to migrate to asynchronous rendering. Then once a subtree is ready, they can opt-in by wrapping in <AsyncMode>.

For new apps, though, the story is different: go async by default. We'll introduce a new root API (a replacement for ReactDOM.render) that is async only.

There will be an awkward period after the initial release where many third-party frameworks (Redux, Apollo, React Router...) may not work properly in async mode. That might hurt adoption for a while. But the idea is that the new features will be so compelling that it won't take long for libraries to either adapt or be superseded by an async-compatible alternative.

Also do you have any tips on how to best prepare (in terms of code written today, that wants to be future compatible with these improvements to React) - polyfills / techniques / etc?

Wrap everything in <StrictMode> and make sure there are no warnings. We'll have more detailed migration guides as we get closer to release.

@hwillson

This comment has been minimized.

Copy link

commented Jul 25, 2018

There will be an awkward period after the initial release where many third-party frameworks (Redux, Apollo, React Router...) may not work properly in async mode.

Apollo doesn't do awkward - we'll be ready! 🕺😳

Seriously though, we ❤️ all things React, so making sure we're in-line with these changes for the initial release is not only a high priority, but it's also something we're super excited about! Thanks for all of your amazing work on this @acdlite!

@markerikson

This comment has been minimized.

Copy link

commented Jul 25, 2018

I'll chime in and say that the Redux team is working on async compat for React-Redux.

I laid out a potential roadmap at reduxjs/react-redux#950 . TL;DR:

  • React-Redux 5.1 will hopefully work with <StrictMode> with no warnings (current PR: reduxjs/react-redux#980 )
  • 6.0 will be an internal rewrite to use the new context API, add ref forwarding, and possibly other changes, but try to keep as much of the current public API as possible (ie, <Provider> and connect() ). We'll see how well that works with async rendering, and figure out the best path forward. (My prior proof-of-concept PR is at reduxjs/react-redux#898 , but we'll probably redo it based on other lessons learned from the 5.1 work.) It's likely that this release would require React 16.5 as a minimum, due to the need for new context and probably also the as-yet unreleased "read context from lifecycle methods" PR that was just merged.
  • After that, we're open to ideas for a different React-Redux API (yes, yes, that possibly includes render props, people).

We'd appreciate more eyes on our WIP, and hopefully people can give us some more feedback and discussion on how they're looking at using Redux with React Suspense and async rendering so we can make sure use cases get covered properly. We're also hoping to have some more discussions with the React team about exactly what constraints we need to work with, and it'd be helpful if we could get some sample apps that would let us see what problems we need to solve for all this to work correctly.

@anymost

This comment has been minimized.

Copy link

commented Jul 26, 2018

looking forward to the release of Async rendering and Suspense

@giorgi-m

This comment has been minimized.

Copy link

commented Jul 27, 2018

@acdlite Also question about suspense and async rendering.
My question is once they are introduced and one starts writing apps with that new version of react: does it mean that react API and the way people code in react will change too? (even if they don't plan to use features of suspense and async rendering?)

I assume it can be trickier to write react code with suspense and async rendering (maybe due to some new API or other constraints), and for those who don't need it, why force them to use react in a new way? And not allow them to code in react the way they do now?

@gaearon

This comment has been minimized.

Copy link
Member

commented Jul 27, 2018

I assume it can be trickier to write react code with suspense

Have you had a chance to watch the second half of my talk? I'd say quite the opposite — it's way less trickier to use suspense for data fetching than anything else (including Redux, local state, or some other library).

@giorgi-m

This comment has been minimized.

Copy link

commented Jul 27, 2018

@gaearon I haven't. I was speaking more in theory. Imagine there is already set of people who know react. If people don't need the feature of async rendering and suspense, why force them learn "new" react? Especially if the "new" react is tricker to use? But: I am not well informed so I might be wrong say about the "trickier" part - I am just sharing some of my thoughts :).

In a way I am saying if 10% of apps need the feature of Suspense and async rendering, why in those other 90% cases force people to learn "new" react? But again I might be wrong, since I didn't gather much info about suspence and async rendering yet.

@gaearon

This comment has been minimized.

Copy link
Member

commented Jul 27, 2018

I think it's hard to have a conversation if you haven't looked at my demos yet.

To be clear: there's no "new React", these features don't break any existing patterns 🙂. They are additive. You don't need to write code in a completely different way to use those features either — although some of them only work if you use modern lifecycle methods.

While this is not directly related to your concern, I disagree they're "trickier to use". I think suspense is much simpler to use than any other loading mechanism that currently exists. That's the reason I'm so excited about it. But again, you don't have to use any of the new features if you don't want to. Old patterns will keep working.

I really do recommend watching my talk. I'm sure this will make a lot more sense once you see these features in action.

@giorgi-m

This comment has been minimized.

Copy link

commented Jul 27, 2018

@gaearon

All old patterns keep working.

Thanks for feedback Dan. Yeah that is how I thought, I suppose if people don't need those features they should be able to write the way they used to before those features were added.

good luck.

@giorgi-m

This comment has been minimized.

Copy link

commented Aug 18, 2018

Hey Dan(@gaearon), I am not nitpicking but want to figure it out. Above you said:

But again, you don't have to use any of the new features if you don't want to. Old patterns will keep working.

Which would suggest that I can code in new React the same way I did in "old" React, e.g. I could use the life cycle methods in the same way, etc. right?

However, here, bvaughn says that getDerivedStateFromProps (or componentWillReceiveProps) could be called many times for one update, hence his solution not to fetch data inside it.

So my question is, after all, it does seem we can't use the new React in exactly the same way as before right? Because AFAIK in current react componentWillReceiveProps doesn't get called many times for one update, isn't it?

@markerikson

This comment has been minimized.

Copy link

commented Aug 18, 2018

@giorgi-m : yes, the lifecycle methods are changing, but the point is that Suspense itself is an opt-in feature. All your existing React render methods and React's rendering behavior will work as-is. However, if you opt in by adding an <AsyncMode> tag to a part of your app, and you begin using Suspense's approach for indicating async data needs, then you can take advantage of it. None of that happens if you don't add that to your codebase.

@TrySound

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2018

@giorgi-m componentDidUpdate should be used instead of componentWillReceiveProps or getDerivedStateFromProps.

@giorgi-m

This comment has been minimized.

Copy link

commented Aug 18, 2018

@markerikson So you say that what bvaughn said here, that getDerivedStateFromProps can be called many times for one update, is not necessarily the case, if I haven't enabled the <AsyncMode/>?
(sorry for asking such questions just they popup to me from time to time, and didn't find resource which would cover all).

ps. bvaughn also didn't mention the optionality of that in the linked thread, hence it raised my suspicion.

@pshrmn

This comment has been minimized.

Copy link

commented Aug 22, 2018

Should a method for enqueueing asynchronous updates (e.g. deferSetState() for class components as opposed to renderer-specific unstable_deferredUpdates()) be added to the core checklist?

From my understanding, any updates for fibers in async mode will be asynchronous, which in theory means that deferSetState() would be unnecessary. However, the unstable-async/suspense demo mixes a synchronous update and an async update and I'm not sure how that can be accomplished in async mode (for "universal" components).

@gaearon

This comment has been minimized.

Copy link
Member

commented Aug 22, 2018

It’s in the check list for the time slicing umbrella.

@TejasQ

This comment has been minimized.

Copy link

commented Sep 19, 2018

What are y'all using instead of requestIdleCallback?

@NE-SmallTown

This comment has been minimized.

@TejasQ

This comment has been minimized.

Copy link

commented Sep 19, 2018

Ah, of course. Silly me. I was wondering what browser API the scheduler module uses under the hood instead of requestIdleCallback. I should've presented the question more clearly. 😅

@TejasQ

This comment has been minimized.

Copy link

commented Sep 19, 2018

Oh wow, found it.

// The remaining code is essentially a polyfill for requestIdleCallback. It
// works by scheduling a requestAnimationFrame, storing the time for the start
// of the frame, then scheduling a postMessage which gets scheduled after paint.
// Within the postMessage handler do as much work as possible until time + frame
// rate. By separating the idle call into a separate event tick we ensure that
// layout, paint and other browser work is counted against the available time.
// The frame rate is dynamically adjusted.
// We capture a local reference to any global, in case it gets polyfilled after
// this module is initially evaluated. We want to be using a
// consistent implementation.

That is next-level cool.

@nilshartmann

This comment has been minimized.

Copy link

commented Oct 23, 2018

Hi,

while trying to understand Suspense I recognized that I have no idea what part of an app is actually "suspended" when using the Suspend component 😳😱.

In the following example I would expect Title to be visible immediately, Spinner after 1000ms and UserData after ~2000ms (as "loading" the data for that component takes 2000ms).
But what I see is that Title first appears together with Spinner after 1000ms.

// longRunningOperation returns a promise that resolves after 2000ms
const UserResource = createResource(longRunningOperation);

function UserData() {
  const userData = UserResource.read(cache, "Lorem Ipsum");
  return <p>User Data: {userData}</p>;
}

function Spinner() {
  return <h1>Fallback Loading Spinner</h1>;
}

function Title() {
  return <h1>Hello World</h1>;
}

function App() {
  return (
    <React.Fragment>
      <Title />
      <Suspense maxDuration={1000} fallback={<Spinner />}>
        <UserData />
      </Suspense>
    </React.Fragment>
  );
}

unstable_createRoot(document.getElementById("mount")).render(<App />);

(You can find the complete example that uses React 16.6.0-alpha.8af6728 here on codesandbox)

Is there a way to make Title immediately visible and "suspend" only the other part of the application? Or did I misunderstand maybe Suspense completely? (If there is a better way to ask this kind of questions, please let me know)

Thanks!

@TejasQ

This comment has been minimized.

Copy link

commented Oct 23, 2018

Hi @nilshartmann! Great question!

Is there a way to make Title immediately visible and "suspend" only the other part of the application?

If I understand correctly, you'll need to explicitly tell React to not wait before flushing Title to the DOM as in this example in order to make Title immediately visible and "suspend" only the other part of the application by wrapping the parts that you'd expect to be immediately rendered in a <Suspense maxDuration={0}>.

I imagine this is the case because of some underlying lower-level scheduler mechanics? I'd also love to understand this better, but that should solve your problem for now.

I'm excited to hear what's actually going on there.

(If there is a better way to ask this kind of questions, please let me know)

I'm not sure there is. 😄 It seems quite clear to me. Thanks for asking!

@karlhorky

This comment has been minimized.

Copy link
Contributor

commented Oct 23, 2018

@TejasQ In my browser, loading your example renders the fallback spinner right away. Shouldn't it load after 1000ms?

@nilshartmann

This comment has been minimized.

Copy link

commented Oct 23, 2018

@TejasQ thanks for your answer, but @karlhorky is right: now spinner shows up immediately.

@TejasQ

This comment has been minimized.

Copy link

commented Oct 23, 2018

Yikes! I missed that. I tried. 😅Let me take another look at it and get back to you. I must have missed something. 🤷‍♂️

Update: I'm trying to figure it out here and we can collaborate if anyone's interested to do it together in realtime.

Second update: @philipp-spiess and I have looked at it and I am genuinely stumped. I still don't understand it. At this point, I'm not sure if it's a bug since this is, in fact, an unstable_ and alpha feature, or if it's something that I am simply not seeing.

In either case, I feel like the core team will either have helpful answers, or be able to use your question to make React even better/more approachable.

Let's see what they have to say. 😄 Thanks for pointing this out, @nilshartmann!

@Jarred-Sumner

This comment has been minimized.

Copy link

commented Oct 24, 2018

Was this released as part of React v16.6? The blog post shows example code using Suspense:

import React, {lazy, Suspense} from 'react';
const OtherComponent = lazy(() => import('./OtherComponent'));

function MyComponent() (
  <Suspense fallback={<div>Loading...</div>}>
    <OtherComponent />
  </Suspense>
);
@gaearon

This comment has been minimized.

Copy link
Member

commented Oct 24, 2018

Was this released as part of React v16.6?

Only the lazy loading use case, and only in sync mode. Concurrent mode is still WIP.

@nilshartmann

In the following example I would expect Title to be visible immediately, Spinner after 1000ms and UserData after ~2000ms (as "loading" the data for that component takes 2000ms).

I do think you're a bit confused about what maxDuration does. It's a new mental model but we haven't had time to document this yet. So it'll keep being confusing for a while until concurrent mode is in a stable release.

@ghengeveld

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

Congrats on announcing the hooks proposal. I'd like to share something with the team. A while ago I released a component called React Async, which has features similar to Suspense. Essentially it handles Promise resolution, and provides metadata such as isLoading, startedAt and methods like reload and cancel, all with a declarative API (and a useAsync hook is on the way).

Now my main concern is how this will integrate with Suspense. For the most part I can probably use the Suspense APIs from React Async and provide users with the familiar and simple React Async API, while offering Suspense's scheduling features for free. For what I've seen, I genuinely think the React Async API is more sensible and approachable compared to the more abstract Suspense APIs. Essentially React Async tries to offer a more concrete API that works for a slightly smaller subset of use cases.

I was surprised to learn of the React Cache library. For React Async I deliberately did not include a cache mechanism but chose to deal with vanilla Promises. Adding caching on top of that is fairly easy.

Finally I'm concerned about accessing Suspense features from custom hooks. Suspense seems to rely heavily on several built-in components, which makes it impossible (I think?) to use these from a hook. Will there be Suspense hooks? Or is there some other way to integrate the two?

@Dem0n13

This comment has been minimized.

Copy link

commented Nov 9, 2018

Hello. How can I test code with Suspense/Lazy?
now renderer.create(...)toTree() throws
"toTree() does not yet know how to handle nodes with tag=13"

@MuYunyun

This comment has been minimized.

Copy link

commented Mar 4, 2019

Why the props maxDuration in Suspense is only used in the Concurrent Mode rather than both of sync and concurrent mode. Can anyone help explain?

@Jessidhia

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

(Right now) it means how long Concurrent Mode is allowed to leave this tree pending before forcing it to commit -- it effectively controls the time slicing deadline, and time slicing doesn't exist in Sync mode. Waiting before committing the tree would necessarily make the commit... not Sync.

@danpantry

This comment has been minimized.

Copy link

commented Apr 19, 2019

I've been using Suspense in an internal application for data fetching and very quickly come across the reason why it is not meant to be used for data fetching yet.

Eventually, though, it is meant to be used for fetching data. Given that it seems unlikely the API is going to change significantly except for perhaps the cache provider, how is Suspense meant to work if you need to modify the data after you've fetched it?

As an example, here is a really awful hook from my application.

function useComponentList(id) {
  const incomingComponents = useSuspenseFetch(
    React.useCallback(() => getComponentAPI().listComponents(id), [id])
  )

  const map = React.useMemo(
    () =>
      Map(
        (incomingComponents || []).map(component => [component.id, component])
      ),
    [incomingComponents]
  )

  return useCacheValue(map)
}

This hook:

  1. Fetches data using the given callback from the given endpoint
  2. Transforms that data into an ImmutableJS Map - Since this is potentially expensive, I memoize the operation.
  3. Returns the map wrapped in useCacheValue, which is the particularly awkward bit.

useCacheValue looks like this:

export default function useCacheValue(value) {
  const [state, setState] = React.useState(value)
  React.useEffect(() => {
    setState(value)
  }, [value])

  return [state, setState]
}

with the idea being that it is a hook that will respond to value changing (which indicates that the data was refetched) but allows the user to modify the react apps representation of that state. In a way, it acts like a very bad cache (hence the name).

I'm struggling to see how this pattern works well with Redux in its current state. Has there been any discovery into how this might look when written by a programmer that is not me and when suspense is 'ready' for data fetching? As it stands, this is much more laborious than using Redux on its own with imperative fetching flags.

This probably gets a lot simpler once Redux has its own hooks since the main difficulty in making the two play together is that Redux uses a HOC with a context that is not meant to be exposed, but I'd still like to see what the official answer is :)

@gaearon

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

Suspense is meant to work with an external cache (not a Hook driven by state). We’ll provide a reference implementation of such a cache that works for simple use cases. Relay will implement its own caching mechanism. Any other tools (such as Apollo) will be able to also implement their own cache that’s compatible, possibly getting inspired by these two implementations.

Mutation/invalidation isn’t the only question that needs answers. We also need to think about: when to show spinners, common patterns like “inline indicator” which may be outside the suspended tree, coordinating loading states (for things that need to unlock in a top-down order or come in as they’re ready), streaming rendering of lists, how this affects partial hydration, and so on. We’re working on these things but there’s no “official recommendation” on any of them yet. When there is, you’ll know it from the blog where we announce updates.

As a side note, Suspense for data fetching is a sufficiently different mental model than what people might be used to. I don’t think it’s fair to expect it’ll necessarily be as powerful when integrated with very unconstrained mechanisms like Redux. But we’ll see. It’s hard to say anything right now.

@ntucker

This comment has been minimized.

Copy link

commented Apr 19, 2019

@gaearon When you say "we're working on these things", is there an issue I can subscribe to or are these discussions happening in private?

@danpantry

This comment has been minimized.

Copy link

commented Apr 20, 2019

Thanks, @gaearon :)

@gaearon

This comment has been minimized.

Copy link
Member

commented Apr 20, 2019

@ntucker As always, you can watch ongoing activity as PRs. For example: #14717, #14884, #15061, #15151, #15272, #15358, #15367, and so on. We try to put some descriptive information into each PR, and you can see the behavior changes from tests. The documentation bar for experiments is low for several reasons.

We'll post more complete explanations about the chosen model after we're more confident that it actually works. I don't think it'll be productive either for us or for the community if we painstakingly describe every experiment in detail as it happens. Most of our first experiments fail, and documenting and explaining each and every one of them would slow our work to a crawl.

It is even worse that this often results in people building a mental model around something that we later realize doesn't work in the originally designed way. (Like it's happening with maxDuration which we just removed.) So we'd prefer to hold off sharing half-baked ideas until it's a good use of both your time and our time. This is consistent with how we developed React in the past too. When something is truly ready (even for a theoretical writeup of the mental model), we'll focus all our attention on documenting and explaining it.

@dudo

This comment has been minimized.

Copy link

commented Jun 14, 2019

As a side note, Suspense for data fetching is a sufficiently different mental model than what people might be used to. I don’t think it’s fair to expect it’ll necessarily be as powerful when integrated with very unconstrained mechanisms like Redux. But we’ll see. It’s hard to say anything right now.

@gaearon, fortunately, Suspense's mental model matches with my own perfectly. Very excited for that piece of the puzzle to fall into place. Thank you for all your hard work!

@newtack

This comment has been minimized.

Copy link

commented Jul 29, 2019

The roadmap announced last November (https://reactjs.org/blog/2018/11/27/react-16-roadmap.html) indicated that the "concurrent" version of Suspense was slated for Q2 2019. We are now well in Q3 2019. Is there an update we can get in terms of definitely not Q3, or maybe Q3, etc.?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.