Autosave: 2024-06-15 11:30:03
This commit is contained in:
parent
de8ab6ec6d
commit
fae646bc33
26 changed files with 47 additions and 44 deletions
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
tags: [AWS]
|
||||
tags:
|
||||
- AWS
|
||||
- procedural
|
||||
---
|
||||
|
||||
# AWS CLI frequent commands
|
||||
|
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
tags:
|
||||
- docker
|
||||
- AWS
|
||||
---
|
||||
|
||||
# AWS SAM and Docker
|
||||
|
|
|
@ -6,7 +6,7 @@ tags:
|
|||
|
||||
# Application state management
|
||||
|
||||
Although [useReducer](useReducer.md) and [useContext](useContext.md) have
|
||||
Although [React_useReducer](React_useReducer.md) and [React_useContext](React_useContext.md) have
|
||||
many sound use cases by themselves, when they are combined they offer a way to
|
||||
acheive a system of global state management, without utilising third-party
|
||||
libraries like Redux.
|
||||
|
@ -47,7 +47,7 @@ export const CounterContext = React.createContext({});
|
|||
|
||||
Now we need a reducer that will handle the state updates. We will just use the
|
||||
same setup as we used in the example of
|
||||
[useReducer](useReducer.md#refining-the-syntax):
|
||||
[React_useReducer](React_useReducer.md#refining-the-syntax):
|
||||
|
||||
```js
|
||||
function reducer(state, action) {
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
tags:
|
||||
- operating-systems
|
||||
- Linux
|
||||
---
|
||||
|
||||
# Basic model of a \*nix operating system
|
||||
|
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- shell
|
||||
---
|
||||
|
||||
# Best practices
|
||||
|
||||
https://sharats.me/posts/shell-script-best-practices/
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
tags: []
|
||||
tags:
|
||||
- logic
|
||||
---
|
||||
|
||||
# Biconditional Elimination
|
||||
|
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
tags: []
|
||||
tags:
|
||||
- logic
|
||||
---
|
||||
|
||||
# Biconditional introduction
|
||||
|
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
tags: []
|
||||
tags:
|
||||
- networks
|
||||
- procedural
|
||||
- Linux
|
||||
---
|
||||
|
||||
# Bluetooth
|
||||
|
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
tags: [propositional-logic, algebra, nand-to-tetris]
|
||||
tags:
|
||||
- propositional-logic
|
||||
- algebra
|
||||
- nand-to-tetris
|
||||
- logic
|
||||
---
|
||||
|
||||
# Boolean algebra
|
||||
|
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
tags: [propositional-logic, nand-to-tetris]
|
||||
tags:
|
||||
- propositional-logic
|
||||
- nand-to-tetris
|
||||
- logic
|
||||
---
|
||||
|
||||
# Boolean function synthesis
|
||||
|
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
tags: [propositional-logic, nand-to-tetris]
|
||||
tags:
|
||||
- propositional-logic
|
||||
- nand-to-tetris
|
||||
- logic
|
||||
---
|
||||
|
||||
# Boolean functions
|
||||
|
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
tags:
|
||||
- disks
|
||||
- operating-systems
|
||||
---
|
||||
|
||||
# The boot process
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
tags: [bus]
|
||||
tags:
|
||||
- bus
|
||||
- computer-architecture
|
||||
---
|
||||
|
||||
# Bus
|
||||
|
|
|
@ -1,10 +0,0 @@
|
|||
---
|
||||
id: 81vp
|
||||
title: Change_DNS_server
|
||||
tags: [procedural]
|
||||
created: Saturday, June 08, 2024
|
||||
---
|
||||
|
||||
# Change_DNS_server
|
||||
|
||||

|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
tags: [motherboard]
|
||||
tags:
|
||||
- hardware
|
||||
- computer-architecture
|
||||
---
|
||||
|
||||
# Chipset and controllers
|
||||
|
|
|
@ -2,13 +2,12 @@
|
|||
tags:
|
||||
- javascript
|
||||
- react
|
||||
- react-hooks
|
||||
---
|
||||
|
||||
# Forms using hooks
|
||||
|
||||
With hooks, form processing is exactly the same as
|
||||
[classes](Forms.md) in terms of the overall
|
||||
[classes](Forms_in_React.md) in terms of the overall
|
||||
methodology, but the syntax is slightly different as a result of the `useState`
|
||||
hook.
|
||||
|
|
@ -2,7 +2,6 @@
|
|||
tags:
|
||||
- javascript
|
||||
- react
|
||||
- react-hooks
|
||||
---
|
||||
|
||||
# Iterating through data
|
|
@ -2,7 +2,6 @@
|
|||
tags:
|
||||
- javascript
|
||||
- react
|
||||
- react-hooks
|
||||
---
|
||||
|
||||
# Memoization with useCallback and useMemo
|
||||
|
@ -69,7 +68,7 @@ const handleSubmit = useCallback(
|
|||
);
|
||||
```
|
||||
|
||||
Note that the syntax is similar to [useEffect](useEffect.md): there is a
|
||||
Note that the syntax is similar to [React_useEffect](React_useEffect.md): there is a
|
||||
dependency array. The effect is the same: the function contained within
|
||||
`useCallback` will only re-rendered if one of these dependencies changes.
|
||||
However (see next section) the function will run in its memoized form on every
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
tags: [memory, motherboard]
|
||||
tags:
|
||||
- memory
|
||||
- computer-architecture
|
||||
---
|
||||
|
||||
# Memory
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
tags: [motherboard]
|
||||
tags:
|
||||
- hardware
|
||||
- computer-architecture
|
||||
---
|
||||
|
||||
# Motherboard
|
||||
|
|
|
@ -2,7 +2,6 @@
|
|||
tags:
|
||||
- javascript
|
||||
- react
|
||||
- react-hooks
|
||||
---
|
||||
|
||||
# Errors
|
||||
|
@ -18,4 +17,4 @@ Once the data is returned, React tries to update the state but the component is
|
|||
unmounted.
|
||||
|
||||
As the warning suggests, this can be resolved using the cleanup parameter within
|
||||
[useEffect](useEffect.md#cleanup-functions).
|
||||
[React_useEffect](React_useEffect.md#cleanup-functions).
|
|
@ -2,7 +2,6 @@
|
|||
tags:
|
||||
- javascript
|
||||
- react
|
||||
- react-hooks
|
||||
---
|
||||
|
||||
# `useContext`
|
|
@ -2,7 +2,6 @@
|
|||
tags:
|
||||
- javascript
|
||||
- react
|
||||
- react-hooks
|
||||
---
|
||||
|
||||
# `useEffect`
|
||||
|
@ -81,7 +80,7 @@ recasts the traditional [lifecycle methods](Lifecycle_methods.md))
|
|||
effect runs again (i.e. when it runs in response to a change in one of the
|
||||
elements of the dependency araray). This is chiefly used to prevent
|
||||
[memory leaks](Memory_leaks.md) and the
|
||||
['update on unmounted component error'](Errors.md#state-update-on-unmounted-component).
|
||||
['update on unmounted component error'](React_errors.md#state-update-on-unmounted-component).
|
||||
|
||||
You do this by having a `return` clause after the main effect. Schematically:
|
||||
|
|
@ -2,13 +2,12 @@
|
|||
tags:
|
||||
- javascript
|
||||
- react
|
||||
- react-hooks
|
||||
---
|
||||
|
||||
# `useReducer`
|
||||
|
||||
The `useReducer` hook is best used in scenarios where you are manipulating state
|
||||
in a way that is too complex for the trivial [useState](useState.md) use case.
|
||||
in a way that is too complex for the trivial [React_useState](React_useState.md) use case.
|
||||
`useState` is best employed when you are updating a single value or toggling a
|
||||
boolean. If you are updating the state of an object or more complex data
|
||||
structure, it is often more efficient to employ `useReducer`.
|
|
@ -2,7 +2,6 @@
|
|||
tags:
|
||||
- javascript
|
||||
- react
|
||||
- react-hooks
|
||||
---
|
||||
|
||||
# `useState`
|
Loading…
Add table
Reference in a new issue