It's a Quarter ๐ฟ: The Badtechies FridayOut Newsletter
IBTC FridayOut Newsletter ๐ฟ
Welcome to another end of the week ๐,
We hope you have been having a great week and month.
The month of March will mark the end of a quarter into the new year. How are your goals and plan going? Good or bad, giving yourself an answer is a great way to show self assessment.
Letโs get it ooonnnnn!! 4th of this month, March 2023, we had the clubโs first virtual meetup ๐. We talked about JWT for devs and it was a blast for me as I was exposed to the security side of things. And I am sure it is the same experience for those who came around.
We are looking forward to another virtual event next week Saturday, March 18: A workshop experience to learn React, Types and Jotai, time is 4pm - 5:25pm. The medium to join and posters will be communicated to the club's members in the week.
If you have something you have been learning and or any topic you are confident to give a talk on? Throw Kelvinsekx a message. We look forward to having more virtual workshops like this.
Was this forwarded to you? You can subscribe here!
STUFF THAT ARE WORTH YOUR READ
Software engineers
Types of Request-Response API
Not until 2015, we had just one way, Rest, of handling request-response API, at least for the popularized and standardized part of it. Rest or Restful API had a 15 year reign until in 2015 when Meta came out with GraphQL, then in 2016 Google gave us gRPC.
An API, or application programming interface, is a set of rules that define how applications or devices can connect to and communicate with each other.
From the short introduction, one can easily summarize that we have three types of Request-Response API Standards today: Rest, Graphql and gRPC.
The name request-response might not be popular, but it is only used here as a summary of how those API standards behave.
What you love, isnโt what I love
Rust, Elixir, Clojure, Typescript, and Julia are at the top of the list of Most Loved Programming Languages. But the trend has shown the Junior developers do not care ๐คทโโ๏ธ. They do not influence the most loved languages, seniors do.
Every year Stackoverflow does their Developer Survey thing and one of the sections that calls attention is the Most Loved Programming Language. Well, trend has shown that those languages are loved by seniors and not the Junior lads: they donโt give a fuck.
Python followed by Javascript are what Juniors care about. Read the trend for yourself.
Frontend Developers
Closures are not what you think they are
Because we write majorly in Javascript, as front-end developers we think things come as easy as JavaScript preaches it. This article provides a good explanation of what a scope and closure mean.
In a nutshell, Scopes are lexical environments where variables reside that a function or method has access to while closures are functions that have access to its parent's scope for a longer period of time. Until a closure is called (, or used) it will forever have access to its parent lexical environment.
lexical environment, which is a record of all the variables that are available to a piece of code at any given time. You can replace lexical environments with tables of records or a Ledger.
Next time when you see the word, replace it with Ledger ๐ thatโs what I do too.
See it in action
function parent1() {
const name = "Kelvinsekx";
const age = 34;
return function parent2() {
const sex = "Male";
return () => `${name} is ${age} years, and he is
${sex}`;
};
}
const parent2 = parent1(); // parent1 left
const parent3 = parent2(); // parent2 left
console.log(parent3()); // this guy ๐คฃ has access to name and age still. I am a closure ๐.
This could look cheap, but take some time to ask yourself: But after calling parent1, all its local variables should have been destroyed? Yes it should but that is the magic closure does ๐.
If you have not taken the extra minutes to read this section, or if you have even. Take this small test.
Batechies is big on knowledge, we beseech you to attempt these tests
Which of these conditions are true? (there are two true conditions below)
(Please choose an answer, the answer is just few paragraphs below)
A short course: State setters, why are they asynchronous?
If you write react code you must be familiar with useState. Unlike Vue JS, react state variables are updated by a setter, they are not mutable even by design. Keep reading if it starts out confusing.
Here is an example code, how we update states in React and Vue.
Const [state, setState] = React.useState(4);
...
setState(state + 1)
But Vue, it would have looked like
const state = ref(4)
...
state++
From the React's example, calling the useState function (or hook for formality) with an argument returns an array which I then destructured to fetch our state and setState variables. In a more civilized programming language, the returned value from useState is not an array but a tuple.
Array is a data structure that stores a fixed length of literals with same type (naa javascript own different ๐คฃ). Javascript array faults both conditions.
Since state and setState are not the same type, why do Javascript devs call it Array? (All Javascript devs are mad ๐).
setState is a function, state is not. The function (or setState) is a setter, and the state simply picks the value assigned by the setter. A setter is a method or function used to update the value of a specific object.
Back to why they are asynchronous. setState is usually attached to an event, this means they could make multiple calls in seconds. Some people click buttons like they are toys, in some cases you may be in a haste to do something quick then you click multiple interfaces so quick. Whatever it is, events are called all the time.
โฆ
<button onClick={()=>setState(4)}>{state}</button>
The way react handles the multiple call of setState is to put the multiple call into a patch or say an array. So that each one is eventually called.
You can try to create a button in React, and attach a simple console. Then the button as fast as possible 12 time. You'll realize eventually the console will print 12 times.
()=> {
setState(),
setLocation()
}
Since they all go into a patch, it will be terrible for React to call them synchronously. If it happens synchronously, many calls will have been skipped and tired of waiting for the first say 2 or 3 calls. Instead it is only logical that they are asynchronous. This ensures all event calls are eventually called.
Join us next Saturday to learn more about React.
If this Newsletter have helped you understood why Setters are asynchronous, Please Forward it to help someone.
Our answer to the quiz is C and D. A and B are false ๐ค.
Designers
A spark of inspiration from Netlifyโs new logo
Netlify has been going through some heavy brand redesign and the mvp is a new Logo. They shared about the design process and iterations that led them to the new Logo in this blog.
Interesting questions around the web
How large will a tree be to provide oxygen for 100 persons? ๐
SHOUTOUT TO OUR BACKERS
This club and all her activities this month are backed by Jason Palmer, Mark Mayor, Ije and Zakk
We'd love your help sharing this amazing newsletter with more folks in tech! We have over 90 members subscribed to this newsletter and we'd love to get to 1,000 by March, Next year.
If you find this newsletter helpful, Please share it on Twitter (we usually tweet about the newsletter) or LinkedIn, or forward it to someone who can find it useful.
Catch you next time!
Kelvinsekx,
Do not forget to follow us on
Twitter if you haven't, We've been growing.