文章加密

;

2024年4月11日 星期四

react 速成

https://www.youtube.com/watch?v=zqV7NIFGDrQ
https://github.com/scps960740/React-crash-course-2021-bruceFE

 1. Hook: 在编程领域,钩子(hook)是一种技术,允许开发人员在代码的特定点插入自定义代码(like function),以便在程序执行过程中执行特定的操作或修改程序行为。

https://react.dev/reference/react/hooks


**useState is a React Hook that lets you add a state variable to your component. 

const [name, setName] = useState('Edward');

function handleClick() {
setName('Taylor');
setAge(a => a + 1);
  setNumber(function(prev){
    return prev + 100
  })
// ...


<div name={name} />

父子層自動雙向綁定,不用emit


**useEffect is a React Hook that lets you synchronize a component with an external system.(所以當update btn click,應使用useEffect將資料傳給後端,而不是在btn上掛update function)

就像vue的watch with immediate: true

const Home = () => {

  useEffect(() => {

    // 綁定的事件

    return()=>{  // 這個很少用

        // 取消綁定的事件 

    }

  }, [watch的變數]) 

 //如果沒有變數,就是只執行最初的一次,後面沒有監聽(感覺這個是比較不正規的做法嗎嗎嗎???)

//[watch的變數可以不只一個

}


**useRef is a React Hook that lets you reference a value that’s not needed for rendering.


2. jsx

**jsx 就像vue裡的template

**只要想在jsx裡用js就要用大括號

例如:

// List.js   // 這是個component

const arr = [1, 2, 3]

const List = () =>{

    return <div className="list">

       

            arr.map(item => <div>{item}</div>)

        }

        </div>

}

export default List


3. Why shouldn't I use index as key in render a array?

Using the index as a key when rendering an array in React is generally discouraged for a few reasons:


Stability: Indexes may change if items are added, removed, or reordered in the array. This can lead to unnecessary re-renders and potentially affect component state or cause unexpected behavior.


Performance: React uses keys to efficiently update and reconcile the DOM. When using the index as the key, React may have to re-render more components than necessary, impacting performance.


Component State: If components in the array have internal state or rely on lifecycle methods, using the index as the key can lead to inconsistencies or errors when components are re-ordered or removed.


Instead, it's recommended to use a unique identifier for each item in the array as the key. This ensures stability, improves performance, and helps maintain component state integrity. If the array items don't have a unique identifier, consider adding one or using a library like uuid to generate unique keys.


solution 1

use uuid package  如下

import { v4 } from "uuid";


const Edit = ({ add, submittingStatus }) => {

  const [note, setNote] = useState("");

  function noteChange(e) {

    setNote(e.target.value);

  }


  const [date, setDate] = useState("");

  function dateChange(e) {

    setDate(e.target.value);

  }


  const [time, setTime] = useState("");

  function timeChange(e) {

    setTime(e.target.value);

  }


  // TODO del

  console.log(note, date, time);


  function addItem() {

    submittingStatus.current = true

    add(function (prevData) {

      return [       

        {

          id: v4(),

          note,

          date,

          time,

        },

        ...prevData,

      ];

    });

  }


4. 快速模擬後端給資料json-server

https://www.npmjs.com/package/json-server


5.Idempotent

https://ihower.tw/blog/archives/6483

idempotent 的意思是如果相同的操作再執行第二遍第三遍,結果還是跟第一遍的結果一樣 (也就是說不管執行幾次,結果都跟只有執行一次一樣)

根據 HTTP 的規格,GET, HEAD, PUT 和 DELETE 是 idempotent,相同的 Request 再執行一次,結果還是一樣。只有 POST 和 PATCH 不是 idempotent,POST 再執行一遍,會再新增一筆資料,PATCH 則是有不能保證 idempotent 的可能性(徵求例子)。POST 和 PATCH 都不是 idempotent 的操作,這也是為什麼 Github API 裡用 POST 當做 PATCH 的相容取代方案。

另一個 HTTP Methods 特性是”Safe”,這比較簡單,只有 GET 和 HEAD 是 Safe 操作。Safe 特性會影響是否可以快取(POST/PUT/PATCH/DELETE 一定都不可以快取)。而 Idempotent 特性則是會影響可否 Retry (重試,反正結果一樣)。

Safe?Idempotent?
GETYY
POSTNN
PATCHNN
PUTNY
DELETENY
透過 Idempotent 的特性,有時候可以幫助你判斷該用哪一個 HTTP Methods。回到前面講 PUT 好像不太好用,例如以瀏覽器為主的 HTML 應用表單,要麻是 POST 新增資料,要麻就是用 PATCH 部分更新已經存在的資料(你不會希望用 PUT 修改個人資料的時候,每次都要重傳照片吧),因此比較少用到 PUT。這也是為什麼 Rails 4 把表單修改的 PUT 改成 PATCH Method,透過 Rails 鷹架產生出來的 update,其實符合的是 PATCH 行為而不是 PUT。

不過還是有一些我認為蠻適合用PUT的情境,例如訂閱東西該用POST還是PUT呢?

POST /subscriptions
# 還是
PUT /subscriptions/{something_id}
訂閱東西只有兩個狀態,”已訂閱”或”沒有訂閱”,這個訂閱的操作再重送幾次,還是”已訂閱”,所以我認為蠻符合 PUT 的 idempotent 特性。而對應的取消訂閱 API 想當然就是

DELETE /subscriptions/{something_id}
另外一個我覺得有趣又實用的 PUT 例子是,設計 API 给可以離線 offline 使用的行動裝置(例如iPhone)。支援 offline 產生的資料,通常會使用 UUID 來產生 ID,這樣就不需要透過中央伺服器管控 ID,方便裝置之間的同步。這樣的情境下,新增資料的 REST API 其實可以提供兩種:

POST /items # 參數帶 uuid=4937973d-e349-460a-a6ad-38625125b24a。如果不帶uuid則由server來產生uuid
# 和
PUT /items/4937973d-e349-460a-a6ad-38625125b24a
對行動裝置的 client 來說,用POST的問題在於離線環境的不穩定,有可能POST之後沒有收到回傳,因此行動裝置不確定有沒有同步成功,這時候要再重試(retry),但是用 POST 就爆炸了,因為 server 會再新建一筆 uuid 重複的資料。但是用 PUT 就沒有問題了,PUT 是 Idempotent 的操作,可以重送沒有關係 (可以再搭配 Conditional PUT 的機制,用 ETag 和 Last-Modified Headers 確保沒有覆蓋衝突)

如果是沒有 offline 需求的 client,例如第三方應用,那麼就可以用 POST /items 這個 API,交由 server 來產生 uuid。



沒有留言:

張貼留言