Experimental Coding: The Best Programming Habit

Experimental coding, where you build small apps to learn concepts you are unfamiliar with is the best single habit you can learn to develop your programming skill.

#shorts

[asdqwe]

This is honestly the best advice. “What happens if I do this?” Its the only way to make things stick

[sshnavin]

My whole career banks on this, it helps me jump on a new thing quickly and push my org/team to spike things for the real world use cases we build. I would recommend this to anyone starting out, make this a habit, you won’t be irrelevant anytime soon.

[Soda-jqff]

Thanks for this. I ended up making my own state manager implementing it to explore why and spiraled into a mini react.

[johnbull-dev]

Suggested this today to Gov workers. Get your own side project to learn how to do something. Something that interests you, and you can take those ideas and find the code solutions to make it happen.

[kasper]

I am sitting, just chilling on the sofa minding my own business, and suddenly my brain goes: what if you did this in js or that in react, I wonder what would happen

[tkdevlop]

first I thought using only experimental version of all packages 😂

[ILeChriSSI]

I put a console log between the onIncrement assignment and the return statement, like so:
console.log(`count before return = ${count}`),
which is kind of redundant but I actually wasn’t too sure what state count would be in.
Now I am.

[erikslorenz]

I spend most of my time on error handling

[binaryboy]

the set function call will not update the "count const variable" without rerendering and it updates only the "local closure variable", which was created by React itself inside the useState hook function. We have to call useState again to get the latest value, but this happens during render only. So after render, "count const variable" will get recreated and assigned with latest value. Till then we will get only old value from that "count const variable"

[inasuma]

Hmm interesting.

To me this is teaching async programming. “count” is a scalar that only updates after the “setCount” has propagated its result back to the reference, but it won’t happen immediately. Reacts scheduler ensures count won’t reflect its increment until the next render.

This is a critical side effect, basically ensuring the main thread (and UI) doesn’t become blocked by an otherwise passive process (updating state).

My question is, what does the closure have to do with the above?

[jonathanjohnson]

Thanx so much Jack. How proficient should I be in javascript to attempt using React. The syntax looks very similar in the code you used in the video. Great advice for any beginner💯💯👍👍

[TarekFaham]

Man, sometimes I think you're taking ideas from my head...

[kirkkennedylincoln]

Can you talk about concurrency in React?

[tinmancode]

me using work code to expriment, work smart, but dont blow up prod

[Tai]

isnt it logs its previous value because the component did not rerender yet !

[shankar]

Why console always logs its previous value..for example, increasing a count of 1 its logging a value of 0 and increasing it to 2 logging a value of 1 and so on

Why is that happening, state always has a latest value, right?

[chandrashekark]

This comment section alone is teaching me lot of stuff.

[adityaanuragi]

This is because setState isn't "inline" it's actually" asynchronous" so it'll happen when there's nothing left in the call stack or in leymans terms when there's nothing left to do

If setState was inline instead of asynchronous then this code would console out 1 rather than 0 but since it's asymchronous it doesn't

Another example
useEffect is also asynchronous whereas useMemo is inline
So if useEffect and useMemo have the same dependency useMemo will always run first