Thanks for the solution. This works well.

I have one more question.. I also need to instrument the contents of <script type='module> tags. This tag's contents should be treated as module, not script, right? Then is it that there will be cases that we get a transformation error when we give the sourceType: 'script' option for this?

PR to fix that? sorry I'm still starting with this library, so I'm not enough expert for contribute in fixing errors.

This is an interesting use case but it's also quite problematic to handle right now and supporting this out of the box in the current injectGlobal could have been a breaking change.

You can implement your own version of injectGlobal under 20 LOC that would support this:

import { serializeStyles } from "@emotion/serialize";
import { StyleSheet } from "@emotion/sheet";
import { serialize, compile, middleware, rulesheet, stringify } from "stylis";

function injectGlobal(...args) {
  const { name, styles } = serializeStyles(...args);
  const sheet = new StyleSheet({
    key: `global-${name}`,
    container: document.head
  });
  const stylis = (styles) =>
    serialize(
      compile(styles),
      middleware([
        stringify,
        rulesheet((rule) => {
          sheet.insert(rule);
        })
      ])
    );
  stylis(styles);
  return () => sheet.flush();
}

You can check out the demo here. It's using React for rendering as that was just convenient for me but doesn't use any React-specific APIs for styling.

@jordisantamaria sure! if that's an issue would you like to submit a PR, please? 😃

Can can this error also be resolve for @testing-library/vue please.

Yeah, in hindsight, I think that we will do something this week. We still need to add support for React v17 and we can release.

You can search them with the "Select" label, there are too many.

Ahh that's a bummer - I was also hoping for a soon v4 release of this as we will need to work on many upgrades like Typescript 4.1, react 17, ... and preparing for the Material UI v5 release 🎉 . Waiting until Q1 would mean also hold off on all other upgrades and then we would need to do all at once 🙈 - so if there is away (other than sprinkling @ts-ignores over all components) that would be much appreciated 🙏🏻

I don't understand why this is not already in the plugin. Such an important addition

@oliviertassinari Thanks for the reply. Can you link those other issues here?

Yup - if you look at the code, it would seem that you can replace

    if (nextDeps.length !== prevDeps.length) {
      warning(
        false,
        'The final argument passed to %s changed size between renders. The ' +
          'order and size of this array must remain constant.\n\n' +
          'Previous: %s\n' +
          'Incoming: %s',
        currentHookNameInDev,
        `[${prevDeps.join(', ')}]`,
        `[${nextDeps.join(', ')}]`,
      );
    }

with

if (nextDeps.length !== prevDeps.length)
  return false

and then my use case would be supported and there would be no other negative effects.

So I'm asking the team what is the purpose of this warning and also why not change it?

We should do this.

Hey! Not sure about the solution. Would need to look into it. But feel free to create a PR.

Anyway for your code, I feel there's a more efficient way.

const userIds = users.map(u => id)

useEffect(() => {
  if(!userIds.length)
    return
  ...load more stuff by querying endpoints about these ids and set state..
  // since you are setting state here, component will be rerendered, causing the above array.map
  // to re-run and thus userIds is re-computed every render unnecessarilty.
}, userIds)

What could be better

// so now userIds is only re-computed when users change and not whenever state is set
const userIds = useMemo(() => users.map(u => id), [users])

// here effect only re-run when userIds is recomputed, which in turn depends on users
useEffect(() => {
  if(!userIds.length)
    return
  ...load more stuff by querying endpoints about these ids and set state..
}, [userIds])

Or if you don't need to use variable userIds anywhere else

// this case, same as above, effect only re-runs when users change
useEffect(() => {
  const userIds = users.map(u => id)
  // ....
}, [users])

Some other props of user may be changed, but useEffect should depend only on users.map(u => u.id). How to accomplish in this case?

I really cannot find out why the difference between codesandbox and the project

Yes, i use connect(mapStateToProps, mapDispatchToProps)(Card)

It seems that February 29th is not accounted for when using add in a browser.

in node: add(new Date('2020-02-28'), { days: 14 }) // returns "2020-03-13"

in browser: add(new Date('2020-02-28'), { days: 14 }) // returns "2020-03-12"

Thank you! I added this PR https://github.com/mdn/data/pull/450 in hopes it gets merged before applying this patch

@benknight I don't think that it would be good enough, we need to demonstrate dark mode is supported without forcing developers to change their whole OS settings.

Please provide a minimal reproduction test case with v5. This would help a lot 👷 . A live example would be perfect. This codesandbox.io template may be a good starting point. Thank you!

Makes sense. Sorry for my ignorance 😄 Maybe we should still provide a path? and if you think not — consider also contributing to Starship with this very helpful link: https://github.com/starship/starship/blob/master/docs/README.md#powershell 😃

Thank you @artursvonda for re-opening. Is there a plan to fix this soon? If not, can you tell if what @YoonjiJang suggested (changing the > to >=) is a good fix?

Wow! thanks. We need to add it to the docs. Thanks for solving the mystery 🙏

When compiling, the background is set without quotes. Such background rejects Yahoo mail. How to get single quotes during compilation. Or how to display a background for Yahoo. Thanks!

should be:

style="background: url('https//.....')..."

This bug still exists; why was it closed?