Each fiber is still rendered synchronously and it can just pause rendering between fibers.

I wonder, does that actually mean that when one component is paused, the other is rendering? That wouldn't cope well with any global state unless it's tied to fiber which we don't have access to.

I think it would be worth trying to run current tests with Concurrent mode (+experimental React versions) to see a true behavior. Switching to CM should be possible with RTL custom render.

Maybe I am wrong, but isn't outline used by some accessibility devices which are able to focus paragraphs and other blocks?

I am not sure what you mean. Clearly the bug here is that red.500 is not translated to correct color and the browser considers that invalid value and as such it will show default outline for the button.

Describe the bug A clear and concise description of what the bug is.

Using eg. outline="red.500" it's left as-is instead of transforming it to correct color.

Expected Behavior A clear and concise description of what you expected to happen.

Color should be transformed.

@chakra-ui/core: 0.8.0

@SrBrahma Please, don't comment on old and closed issues as only a few people will see that here.

You can use GH Discussions now if you want to dive deep into a performance talks. However, keep in mind that without any sort of benchmarks it's purely theoretical and every step you take to improve perf can as well make it worse.

Also, it was said in many other places. MobX is not built with performance as a major concern. It's made to offer a great developer experience which of course comes with tradeoffs. In summary, if you are building something that needs really every bit of performance, then MobX is not a right tool for you. With regular apps it hardly matters and performance bottlenecks are usually somewhere else.

There is already discussion about strict mode: https://github.com/davidkpiano/xstate/discussions/1248

But I believe that after taking care of https://github.com/davidkpiano/xstate/issues/1250 the strict mode won't be necessary.

@mekwall If you can make a PR I don't have a problem merging such a change, but include react-native as well.

Since batchingForReactDom.js requires react-dom it should be listed as an optional dependency.

This fixes the following issue when used with Yarn v2:

Module not found: mobx-react-lite tried to access react-dom, but it isn't declared in its dependencies; this makes the 
require call ambiguous and unsound.

Why would you even use mobx-react-lite without React? :) And with this reasoning of yours, we would need to include react-native as well and only confuse people.

It doesn't matter, we are planning to change the way this works soon. Use https://github.com/mobxjs/mobx-react-lite/issues/296 for tracking when it happens.

The service is/was down and it caused crash in our app running on Heroku. Am I doing something wrong somewhere? I certainly don't want to try/catch every logging attempt 🙈

@adnanrahic Thanks, I will upgrade, but I guess it would be hard to confirm as it kinda needs Logsene to be down which happens rarely. However, your code change to emit a warning makes sense, so hopefully, it will be alright 🤞

@urugator I might be misunderstanding something, but wouldn't be a problematic with Concurrent mode to have global variables that assumes that only one component is currently rendered? I thought that's what CM is trying to solve to render multiple things at once.

<!-- Thanks for taking the effort to create a PR! 🙌

🚨🚨🚨 IMPORTANT NOTICE 🚨🚨🚨

Next major of MobX V6 is under development. Try to direct all changes toward `mobx6` branch instead of `master`.

🚨🚨🚨 IMPORTANT NOTICE 🚨🚨🚨

👋 Are you making a change to documentation only? Delete the rest of the template and go ahead.

👋 If you are creating an extensive PR, you might want to open an issue with your idea first in case there is a chance for rejecting it.

👋 If you intend to work on PR over several days, please, create [draft pull requests](https://github.blog/2019-02-14-introducing-draft-pull-requests/) instead.

👇 Please look at the following checklist to ensure that your PR can be accepted quickly:

-->

Code change checklist

• [ ] Added/updated unit tests
• [ ] Updated changelog
• [ ] Updated /docs. For new functionality, at least API.md should be updated
• [ ] Verified that there is no significant performance drop (npm run perf)

<!-- Feel free to ask help with any of these boxes! --> fix https://github.com/mobxjs/mobx/issues/2413. The following image shows the result after the fix.

<a href="https://gitpod.io/#https://github.com/mobxjs/mobx/pull/2420"><img src="https://gitpod.io/api/apps/github/pbs/github.com/MoonBall/mobx.git/da27c1fe4015916a548419bf837990cc34ce18e1.svg" /></a>

Mobx Footer Logo Alignment Fix.

Description: - Above the Docs section, the logo should be aligned with other section of the footer

Screenshot:

Environment:

• OS: Windows
• Browser: Chrome
• View mode - iPhone 6/7/8 IOS
• Version: Version 81.0.4044.113 (Official Build) (64-bit)

I would love to work upon this issue !

Thanks!

<!-- Thanks for taking the effort to create a PR! 🙌

🚨🚨🚨 IMPORTANT NOTICE 🚨🚨🚨

Next major of MobX V6 is under development. Try to direct all changes toward `mobx6` branch instead of `master`.

🚨🚨🚨 IMPORTANT NOTICE 🚨🚨🚨

👋 Are you making a change to documentation only? Delete the rest of the template and go ahead.

👋 If you are creating an extensive PR, you might want to open an issue with your idea first in case there is a chance for rejecting it.

👋 If you intend to work on PR over several days, please, create [draft pull requests](https://github.blog/2019-02-14-introducing-draft-pull-requests/) instead.

👇 Please look at the following checklist to ensure that your PR can be accepted quickly:

-->

Code change checklist

• [ ] Added/updated unit tests
• [ ] Updated changelog
• [ ] Updated /docs. For new functionality, at least API.md should be updated
• [ ] Verified that there is no significant performance drop (npm run perf)

<!-- Feel free to ask help with any of these boxes! -->

The first image below show the case that BLM covers the input search. The second image below show the result of the fix.

<a href="https://gitpod.io/#https://github.com/mobxjs/mobx/pull/2421"><img src="https://gitpod.io/api/apps/github/pbs/github.com/MoonBall/mobx.git/ab0673407050f133f41232f22a5f36b4be14c3fd.svg" /></a>

Thanks!

@olee If you want to try to implement it in the repo with tests, it would be probably best. I won't have spare time in the near future, sorry.

Shouldn't support considerations be left to browsers and developers? I mean, it's in the spec, so it should be part of the API.

@yuwanlin I am thinking it should work the other way around and expand mobx-react-lite to work with React.forwardRef directly instead of extra option. And possibly using that option could produce a one-time warning about deprecation and remove it from the next major. So if you are interested in that, go ahead.

There are huge changes to docs in mobx6, this would only collide with them. If you want to help, try to integrate your changes in there.

I am using an express server where I am using relfect meta data to wrap my controllers. The controllers render a react component that has components with mobx decorators. When using mobx decorators with reflect meta data I am getting this error.

TypeError: at DecorateConstructor (/Users/thebedroomprogrammer/code/src/code.gamezop.io/Gamezop/peach/node_modules/reflect-metadata/Reflect.js:544:31) at Object.decorate (/Users/thebedroomprogrammer/code/src/code.gamezop.io/Gamezop/peach/node_modules/reflect-metadata/Reflect.js:130:24) at __decorate (/Users/thebedroomprogrammer/code/src/code.gamezop.io/Gamezop/peach/ui/src/v2/components/ToastNotification/index.tsx:4:92) at Object.<anonymous> (/Users/thebedroomprogrammer/code/src/code.gamezop.io/Gamezop/peach/ui/src/v2/components/ToastNotification/index.tsx:16:24) at Module._compile (internal/modules/cjs/loader.js:776:30) at Module.m._compile (/Users/thebedroomprogrammer/code/src/code.gamezop.io/Gamezop/peach/node_modules/ts-node/src/index.ts:858:23) at Module._extensions..js (internal/modules/cjs/loader.js:787:10) at Object.require.extensions.(anonymous function) [as .tsx] (/Users/thebedroomprogrammer/code/src/code.gamezop.io/Gamezop/peach/node_modules/ts-node/src/index.ts:861:12) at Module.load (internal/modules/cjs/loader.js:653:32) at tryModuleLoad (internal/modules/cjs/loader.js:593:12)

Duplicate https://github.com/mobxjs/mobx-react/issues/756.

TL;DR There isn't much we can do about it, so closing.

Please setup a reproduction. We can't help you without any code.

I take it back, problem is still the same. I suppose it's a different kind of error than EAI_AGAIN.

The service is/was down and it caused crash in our app running on Heroku. Am I doing something wrong somewhere? I certainly don't want to try/catch every logging attempt 🙈

Looks like it's working with the latest [email protected]. Thanks.

The service is/was down and it caused crash in our app running on Heroku. Am I doing something wrong somewhere? I certainly don't want to try/catch every logging attempt 🙈

No. As Michel explained above it's a generally bad idea to delay rendering. You can solve it in userland if you desperately need that for whatever reasons (eg. react-debounce-render).

Thanks @agilgur5, that's really interesting. It's true that on WIndows machine itself I have Node 10.20.1, so that would be probably a reason why it works there.

At least on Ubuntu I can use NVM. Upon switching to 12.16.3 it works as well, but 12.17.0 is where it got broken apparently. So I am fine with a solution like that.

useObservable is deprecated :) I know, bit confusing similar names, but it's hard to come up with better ones.

If you are accessing observable data in the hook, you can use useObserver. It is considered low-level API, but for cases like, it's perfectly fine. Just replace it with your useMemo

Current Behavior

Expected behavior

It should finish the build successfully.

Suggested solution(s)

I am not sure if it doesn't boil down to some issue in Babel, would like to know your opinion before escalating it.

Additional context

The WSL 2 is the latest Windows Subsystem for Linux. So far it worked pretty well for all tasks, this is the first bummer. Running build directly on Windows works without an issue, so that's some potential culprit here. Unless it's a problem of Ubuntu (or any *nix system). I can't verify that.

I tried to reproduce the issue in some minimal environment, but no luck so far. The same is happening when building either mobx-react or mobx-react-lite packages. You can clone those and try npm run build, but I don't suppose anyone here has access to Ubuntu or Windows :)

Your environment

<!-- PLEASE FILL THIS OUT -->

Summary

The useObservable hook should allow to throttle an update.

The reaction from mobx already allows this : https://mobx.js.org/refguide/reaction.html#options

Use case :

I have a currentTime observable value that is updated every second.

I want to show the current time, but only every 5 secondes.

function MyComponent (props) {
  const currentTime = useObservable(() => myStore.currentTime, null, { delay: 5000 })
  const currentDate = useMemo(() => convertTimestampToDate(currentTime), [currentTime])

  return <div>{currentDate}</div>
}

Current behavior

The component renders every second

Expected behavior

The component should render every 5 seconds

useObservable was deprecated in 1.x and it's gone in 2.x. Make sure to update.

The successor is useLocalStore and it doesn't support delay because setting up observables is unrelated to reactions. If you need to delay your reaction, you do that with useEffect as you have outlined.

…should get display name from 'target' and not 'this'

Code change checklist

• [x] Updated changelog

Thanks!

I think you are missing the point here. It should work the same way across both libraries.

We will publish a fix soon, it was merely an oversight.

Do you mind updating the changelog as well?

Well, the only modification I am doing is adding those webpack aliases to the original CRA config. There is no hidden magic or webpack plugin behind it. When I do the same in Storybook config it's pretty safe to assume it will behave the same way.

I think there is something in Storybook webpack config that's different from CRA's one that prevents this approach. I tried to logging out the config, but it spilled way too much information for me to be able to find something in there.

@mrmckeb Thank you for your patience. Have you also noticed, I am using the same aliasing config in Storybook webpack config?

https://github.com/FredyC/storybook-cra-workspaces/blob/master/modules/web/.storybook/main.js#L4

There is no other special webpack configuration done for the CRA. That's why I am not sure why Storybook is not working. There is no problem in finding those aliased imports, but transpiling Typescript files (with explicit declaration) is problematic for some reason.

@ynejati Looks like the issue #887 is related to this change. What is the idea behind using this in here?

Please create a small reproduction.

Published just now :)

Code change checklist

• [ ] Added/updated unit tests
• [x] Updated changelog
• [x] Updated README if applicable

Fixes https://github.com/mobxjs/mobx-react/issues/725 Closed because "Solution is using react-fast-refresh". react-fast-refresh is mostly not production ready. This fix ensures compatibility. I did not manage to recreate react-hot-loader's behavior as unit test.

Looks fair enough. Thanks for your contribution!

Thanks for the report. We are considering a different approach to this whole thing. Stay tuned :)

@viridia It certainly does have it since 6.2.0

@dotansimha Solution is simple, but I need someone to decide what is the "correct behavior". Apparently, it was intended to ignore typesPrefix for some reason.

@mweststrate Probably better for you to decide this.

@MoonBall Is there some actual issue for this PR or just your assumption about performance? You haven't added any tests or explained anything.

Also note, that you are contributing to the upcoming V6 which you are probably not using yet.

Describe the bug I am utilizing TypeScript path aliases with CRA along with Yarn workspaces in a mono repo situation.

Importing files from the aliased path that contains type declaration fails to parse that file when compiling Storybook. The CRA itself has no trouble with that.

Upon removing type declaration the import is working correctly.

To Reproduce I did set up a whole repo to reproduce a problem. Instructions are pretty straightforward, but I've outlined in README the most notable differences from the regular setup.

Expected behavior Files with Typescript declaration should be imported without an issue.

Screenshots

System:

It's even on WOT blacklist ... https://www.mywot.com/en/scorecard/kutt.it

Yea, we are not Instagram, so that's wild comparison :) Let's leave this open and boil over time. Unless more people are going to require it, it's not worth the effort. It's just theoretical optimization.

Besides, there is currently MobX 6 in works, we won't be doing that for current versions.

If you really want that, I recommend you Yalc tool to basically make your own build.

@dotansimha So what about the typesPrefix? Do you have some answer to that, please? The issue got closed accidentally with the PR.

Partial fixes to #3968 as per https://github.com/dotansimha/graphql-code-generator/issues/3968#issuecomment-661670683 I am not sure about prefixes.

So I decided to have a stab at this since it's starting to annoy me.

First thing, I noticed there is an explicit test to ignore typesPrefix. Why is that? Is that some opinion that it "looks ugly"? That certainly shouldn't be like that. If configured, it should be respected no matter what.

https://github.com/dotansimha/graphql-code-generator/blob/1ddabd70d424653f1e9b01819ede255b2cd0c53b/packages/plugins/typescript/urql/tests/urql.spec.ts#L591-L603

I wonder what do you mean by that? I am not aware it would be broken?

@geohuz If you want to make things better, your help is welcome as well. I did my best to make those docs at the time. I definitely want to keep TypeScript there, but if you can come up with the way to have JS there as well, I am open to it.

Let's say that i have code:

export default class Sound {
  protected audio: HTMLAudioElement;

  constructor(private url: string) {
    this.audio = new Audio();
    this.audio.preload = "auto";
    this.audio.src = url;
  }

  play(): Promise<void> {
    return this.audio.play();
  }

  stop(): void {
    this.audio.pause();
    this.audio.currentTime = 0;
  }

  pause(): void {
    this.audio.pause();
  }

  get playing(): boolean {
    return !this.audio.paused;
  }
}

and i want to observe playing but without modyfy this class (lets say that class Sound is some library). We can do something like this:

import { observable } from "mobx";
import Sound from "./Sound";

export default class SoundStore extends Sound {
  @observable playing = false;

  constructor(private url: string) {
    super(url);

    this.audio.addEventListener("play", () => {
      this.playing = true;
    });
    this.audio.addEventListener("pause", () => {
      this.playing = false;
    });
  }
}

Example code: https://codesandbox.io/s/mobix-observe-raw-class-hxr12

My questions:

1. It is a preferred way to do this?
2. It is a way to do this but without creating a new class extended from this base class?

Looking at original questions

It is a preferred way to do this?

Honestly, try not to look for a "holy grail" of doing something. Anything that works for you is totally fine.

It is a way to do this but without creating a new class extended from this base class?

If the Sound doesn't expose audio element or any sort of callbacks/listeners, then you have to extend it.

I have 2 apps

packages/apps
-- app1
---- mobx@4 # for ie 
---- mobx-react-lite # this have a devDependencies: `"mobx": "5.14.0"`
-- app2
---- mobx@5
---- mobx-react-lite

cause:

That all nice, but that's the problem of your setup, not MobX as it doesn't have any dependency that would cause it.

I think I will close this discussion and I would advise you to take the issue to Yarn as it seems to be the culprit here indeed.

@mks11 Docs are going through a lot of changes for the upcoming V6. You can see the current version at https://deploy-preview-2327--mobx-docs.netlify.app/

Again, what do you expect? You have two mobx versions and they need to be somewhere.

@ananiy I am not sure what outcome do you expect. Each app declares a different version of mobx. If you really need that, you need to nohoist that package itself, not the lite which can be common.

Please elaborate more on your question in detail.

Sorry, but if you have unrelated questions, these are better asked in separate issue with appropriate details.

@observer
class Comp extends React.Component {
  render() {
    return <div>{this.props.p.x}</div>;
  }
}

function Wrapper(props) {
  const p = useAsObservableSource(props);
  // In this case, `Comp` has to be a class component;
  // A functional `Comp` may also cause similar (not exactly identical) render warning in higher versions of `react` and `mobx`.
  return <Comp p={p} />;
}

function App() {
  const [x, setX] = React.useState(0);
  useEffect(() => {
    setX(1);
  }, []);
  return <Wrapper x={x} />;
}

Intended outcome

no error, no warning.

Actual outcome

console error:

Warning: Cannot update during an existing state transition (such as within `render`). Render methods should be a pure function of props and state.

How to reproduce the issue

https://codesandbox.io/s/minimal-mobx-react-project-ve187?file=/index.js

To click the refresh button below while warning is flushed by host.

Versions

• mobx-react: 6.2.2
• react: 16.8.6
• mobx: 4.15.4

Thanks for the report, duplicate to https://github.com/mobxjs/mobx-react-lite/issues/274