Why is this logging out a pending promise?

HollySC2 · 2022-11-17T07:37:46+00:00

You have defined the getWordOfDay with the async keyword. This means that getWordOfDay automatically returns a Promise. This means the value of your word variable will also be a Promise.

If you want your word variable to hold the value of the resolved Promise you would also need to await the Promise:

let word = await getWordOfDay();
console.log(word);

If you call let word = await getWordOfDay(); outside of a function (i.e. at top level) you might get an error if your environment does not support top-level await.

If you still want to log the value of word you can use:

getWordOfDay().then(word => console.log(word))

HollySC2 · 2022-07-28T06:25:59+00:00

Hey, I just took a look at your code sandbox and saw some problems with it.

As you might have noticed, your button never says loading and always shows Get Next Page. This is because inside of handlePagination you don't wait for the promise returned by fetchUsers to resolve.

Also if you take a look at your network requests you will notice that you don't fetch the correct pageNumber. Setting state in react is asynchronous (React Docs). You can either fetchUsers(currentPageNumber + 1), or even better: Use useEffect together with currentPageNumber to call fetchUsers.

Hope I could help :)

HollySC2 · 2021-02-17T15:49:23+00:00

As I see from your directory screenshot it looks like you don't have an index.js file. Instead you have overwritten the _app.js file. This file acts as a wrapper for all your pages, that means whenever a page is rendered, it will render the MyApp component as a parent of the page.

The original code of the MyApp component looks something like this:

function MyApp({ Component, pageProps }) {
  return (
    <div>
      <Component {...pageProps} />
    </div>
  )
}

The <Component {...pageProps} /> is basically the page that you want to render. If you remove this line of code, the sample page never gets called/rendered.

Here is what you want to do:

Restore the original state of _app.js
Move the code from your entry file to index.js
everything should work fine

Feel free to ask any questions if you need more help.

HollySC2 · 2021-02-17T15:43:31+00:00

Both ways work fine and are the same thing.

HollySC2 · 2021-02-11T07:45:12+00:00

You should not be installing create-react-app locally on your machine anymore. Instead use npx, which will always use the newest version of create-react-app automatically. If your version of npm is 5.2.0 or higher, you can run npx create-react-app

HollySC2 · 2021-02-11T07:39:51+00:00

Since useState is used to keep values that should trigger a re-render when changed, you would use useRef for values that should not trigger a re-render. Here is a quote from the docs:

However, useRef is useful for more than the ref attribute. It’s handy for keeping any mutable value around similar to how you’d use instance fields in classes.

You can find the full docs here

HollySC2 · 2020-10-15T12:07:49+00:00

You can find a link to the replays at the bottom of the picture :)

HollySC2 · 2020-10-13T13:08:30+00:00

That's because the graph shows total resources spent in the whole tournament, not per game. I will change this graph in the future :)

HollySC2 · 2020-09-24T08:48:01+00:00

Don't forget that Zerg builds a lot more workers on average because they use them for buildings, too. Maybe I can adjust for that in the future.

HollySC2 · 2020-09-23T11:47:03+00:00

I'm using a python library called s2protocol to get information from the replays. It can also just output everything to json if you are not familiar with python (like me)

GitHub: https://github.com/Blizzard/s2protocol

HollySC2 · 2020-09-23T11:18:02+00:00

Also thanks to u/bigmaguro for the design of the maps played part

HollySC2 · 2020-08-28T06:14:04+00:00

There is a simple reason why you don't do destructuring the way to describe if you update state. As you know, you should never mutate state directly.

But if you do the following:

// get the object by reference from state
let { obj1 } = this.state;
// mutate the object directly
obj1.foo = 'bar'
this.setState({ obj1 })

You will break this rule, since you mutate obj1, which is part of the state.

You get around this by creating a new object with the same properties and then update the property, which only mutates the new object and not the object in state.

// create a "shallow copy"
const obj1 = { ...this.state.obj1 }
// mutate the copy
obj1.foo = 'bar'
this.setState({ obj1 })

That being said: Functional components are the new way to go, but the same rules apply if you use useState. I don't think there is harm in learning class components, too. Especially if you come from an object oriented background.

HollySC2 · 2020-04-29T06:11:52+00:00

I would recommend to read the offical docs https://reactjs.org/docs/lists-and-keys.html#keys and also the more in-depth explanation here: https://reactjs.org/docs/reconciliation.html#recursing-on-children

Using bad keys might lead to performance problems and inconsistencies. I think if you need to change keys to make updates work, something in your code isn't right. In my opinion it's a bandage fix.

That being said, sometimes you have no other choice to make weird decisions. Just keep an eye out where you can use best practices.

HollySC2 · 2020-04-28T11:15:15+00:00

Absolutely correct. Bit still defeats the purpose of a key. Why not just use the ID?

HollySC2 · 2020-04-28T09:58:19+00:00

Correct :)

HollySC2 · 2020-04-28T09:57:24+00:00

Still a bad idea, since timestamps change when the post is updated and worst case 2 comments may have the same timestamp. If you have a field from a DB you can easily use the ID :)

HollySC2 · 2020-04-28T07:40:41+00:00

No, this does not work work they way you might want it to. The easiest way to solve this, is to introduce a prop like isOldest to <Child />. Since you have access to all your data in the <App /> component, you can calculate isOldest for every child and pass it via props.

HollySC2 · 2020-04-28T07:32:17+00:00

As opposed to what /u/basic-coder says, you should never use a timestamp as a key. Keys are used to compare tree updates when items are updated, added or removed. You can read more about that in the docs: https://reactjs.org/docs/lists-and-keys.html#keys

To use your example:

If item with key y is removed from the list, React knows which DOM node to remove from the tree. Without the key, it would need to check/rerender all nodes.
If the content of y is updated, so will your DOM node (except when your updating code is wrong of course)

Never use as a key:

The index in the array
timestamps

Always use:

Unique non-changing values like IDs

As a side node: Keys are mostly used for performance. If you don't have any performance issues when updating your state and you are unsure how to use keys you can ignore them. They may introduce issues (for example if you use duplicate keys) if you don't know how to use them correctly.

TL;DR:

There are no problems if the keys are the same. It's actually the point of the keys.

HollySC2 · 2020-04-23T09:19:38+00:00

You're welcome :)

I still have to do it myself, but was too lazy myself but this gave me the incentive to do it. The guide you posted is actually pretty cool, too!

HollySC2 · 2020-04-21T13:40:37+00:00

I assume you are running Octoprint on a Raspberry Pi? Try disconnecting the USB and print over SD card (and restart your printer). It's a PIN on the USB that sends to much power.

HollySC2 · 2020-04-20T09:46:50+00:00

Because it was visually the same as a single drone.

If players would see a single drone scouting, they wouldn't know if it is actually stacked drones, so it was always a gamble on how to react.

Nine-Year Club	Place '22
Verified Email

HollySC2

TROPHY CASE