你們使用react開發項目react-hooks用的多嗎?

01-18

我一看hooks感覺class好像白學了

hooks雖然是大勢所趨，而且寫出的代碼看起來也比較"乾淨",但是寫出bug的機會遠遠大於class並且是非常不易排查出來的的bug

現在我寫react的項目，基本上只用hooks了，而且使用官方提供的hooks，可以自己實現很多的功能，而且比class component的實現也簡潔不少。

無論是class component，還是function component，都是要根據項目和自己的習慣來決定的，兩種方式都是能實現對應的功能，性能上也機會沒什麼差別。還是要看團隊和個人的習慣。

從我個人來講，已經很習慣使用hooks了。

我們有部分場景用到了hook，並且也的確節省了很多的邏輯復用，你要用hooks，首先要理解他主要解決了什麼問題提出的，class和hooks也並不是對立的

class component可以保證組件良好的可讀性，hooks可以保證邏輯代碼復用性

大多時候你可以將之前hooks component 作為claas component 的container

現在react router以及redux應該都支持hooks寫法（我還沒有升級這兩個）

react的前端ui框架antd4.0也基本都用hooks重寫

所以跟進是必然的，即使你不用，你也要看懂別人的代碼才行啊

已經忘記了 react 的生命周期

我司基本過去一年舊項目和現在新項目已經全hooks重寫，好處就是短平快，當然也不是銀彈，有些複雜邏輯場景function component過了百行看起來非常頭疼，如果有複雜的組件交互和數據傳遞，需要特別注意【重渲染】這個坑，內部實踐過程中已經日常無數次浪費時間在"為什麼值變了"以及"為什麼值沒有變"這個問題上，需要對內部開發者整體素質比較高的要求。

這世界總是有守舊派，但是世界的發展方向總是向前走，守舊派總是難以改變思維，除非你強制給他真香。

class 這種操作，代碼難寫，不好測試，耦合嚴重，即便搞些模式也沉重不堪，現在沒有用的，基本是react還沒升級的，要麼就是shishan。

超級無敵好用，完全可以取代大部分的class組件。

尤其是大部分數據以及業務邏輯基本相同的組件，抽離出一個公共的reducer，復用起來簡直不要太happy！

目前暫時沒有遇到需要用class組件來寫的業務，如果大家有遇到，歡迎評論區討論學習呀！

混著寫完全沒問題。大致有個原則：route下的page頁面完全用class寫法，子組件大部分使用hooks，複雜的組件也還是class寫，主要是class的看起來比較直觀，要不然一堆useState、useCallback都看懵了。

項目已經用 hooks 重構，hooks 的優點在我看來，是一切都可以自動化的去運行，以及可以特別方便的進行代碼復用。

挺多的

大概是因為新用react不久的原因，所以hooks用得不多，主要還是class的那一套。

如果我決定function base的話，應該會全轉hooks。

沒什麼白學不白學的，oop有其存在的理由跟優勢，oop寫出來的代碼簡潔易懂好debug。

至於function base的話，要寫好其實也不容易。

當然你要混用。。。我也沒話說，代碼清晰明了就好

hooks真正上線時間還不算太久，用在公司項目里的應該還不太多，但是作為發展趨勢，以後肯定會越來越多，畢竟是react的主推版本，而不是作為一個可選配置。學起來吧。我的github有hooks的基礎demo，歡迎一起學習

react-hooks目前使用很廣泛，react趨勢是使用hooks，類組件也有使用，具體根據業務場景分析

聽說隔壁Java都在支持函數式了，用hooks沒毛病

什麼樣的公司才能接觸到react的項目呢？

自從hooks發布已經一直在用，確實挺不錯的，但是內部狀態、方法相互依賴的問題處理會非常非常非常的麻煩，我只想說是花樣式警告。

你學class也是應該的，根本不存在白學的問題，畢竟也是react開發的核心基礎知識。

技術多不壓身，做技術這行不存在白學這回事，只是分配精力的力度關係而已。

多，除非是 shishan ，否則都換成 hooks 了。

不理解題主說的 class 好像白學了，我尋思 CC 那一套不就是生命周期?狀態更新嗎？其他的都是 js 里的東西，而且這組件生命周期和狀態更新也是在使用 FC x hooks 的時候需要的兩種知識前提呀。

hook 是大趨勢，但也不是銀彈。class 的可控性是很好的，hook 雖然寫得爽，如果寫得不太規範，可能會導致一系列的問題。hook 的部分 api 依賴項畢竟需要手動寫入，雖然官方提供了相關 lint 插件來規避，但極易受開發者代碼影響。class 和 hook 其實並不矛盾，混合著用也沒問題，現階段 hook 也沒辦法完全取代 class，介於 react 官方會主推 hook，以後 hook 應該能完全取代 class，可以先用起來，畢竟寫起來是真的酸爽……

react-hooks出來才沒多久，可能很多地方還不成熟。

在react-hooks沒形成之前，都用了其他的第三方方式去實現，如果早期項目很大，肯定不可能一個個的來用react-hooks重構，那需要花費大量的精力和人力。

但是以後肯定會越來越多的使用react-hooks的。

也不排除混合使用的情況。但是react-hooks是以後的趨勢

class組件和function組件最終都只是ui的載體，業務邏輯和ui怎麼分離是大家一致探索的方向，在class時代走過了各種套路和姿勢，hoc，renderProps是手段，redux(dva, rematch)、mbox等是具體實現，以dva,rematch為例，沉澱出的一套 ui ---&> dispatch action to effect ---&> update store data ---&> notify ui re-render模式其實用起來已經很順手了，但是hook一出，業務邏輯則封裝成一個個hook了，所以class和function組件邏輯共享成了巨大的問題，大家只能2選1，但是我們可不可以換個思路呢？

把class組件和function組件只看ui的載體，無論是hoc，renderProps，還是hook，都看作是分離業務邏輯和ui的手段，讓他們都走ui ---&> dispatch action to effect ---&> update store data ---&> notify ui re-render這一套經典模式難道不可以嗎？

concent https://github.com/concentjs/concent 讓這個目標成為可能，基於注入實例上下文的原理，統一了class組件和function組件的邏輯共享方式，統一它們的生個周期定義方式，同時內置依賴收集系統，精確渲染你的ui節點，攜帶了大量新特性(setup, computedwatch, lazyDispatch, renderKey等)增強你的組件但是都是可選的，按需使用就好，保持簡單是concent的終極目標。

以下是三個todo-mvc實戰示例，可以對比下代碼的精簡程度，或許能得出你想要的答案：

concent https://codesandbox.io/s/todoapp-react-concent-fvgvc

mbox https://codesandbox.io/s/todo-mvc-mbox-k42q1

reduxhook https://codesandbox.io/s/todo-mvc-redux-49kg0

以下一段代碼演示依賴收集系統（注意哦，無任何根Provider包裹，意味著你的項目可以隨時無痛接入concent，無需其他改造）

https://codesandbox.io/s/concent-watch-7j0mw

import React from "react"; import "./styles.css"; import { run, useConcent, defWatch } from concent;


run({

  login:{// 定義login模塊

    state:{// login模塊state

      name:c2,

      addr:bj,

      info:{

        sex: 1,

        grade: 19,

      }

    },

    computed: {// login模塊computed

      funnyName(newState){

        // 收集到funnyName對應的依賴是 name

        return `${newState.name}_${Date.now()}`

      },

      otherFunnyName(newState, oldState, fnCtx){

        // 獲取了funnyName的計算結果和newState.addr作為輸入再次計算

        // 所以這裡收集到otherFunnyName對應的依賴是 name addr

        return `${fnCtx.cuVal.funnyName}_${newState.addr}`

      }

    },

    watch:{// login模塊watch

      // watchKey name和stateKey同名，默認監聽name變化

      name(newState, oldState){

        console.log(`name changed from ${newState.name} to ${oldState.name}`);

      },

      // 從newState 讀取了addr， info兩個屬性的值，當前watch函數的依賴是 addr, info

      // 它們任意一個發生變化時，都會觸發此watch函數

      addrOrInfoChanged: defWatch((newState, oldState)=&>{

        const {addr, info} = newState;

        console.log(`addr is${addr}, info is${JSON.stringify(info)}`);

      }, {immediate:true})

    }

  }

})
function UI(){

  console.log(UI with state value);

  const {state, sync} = useConcent(login);

  return (

    &

      name:&

      addr:&

      &


      info.sex:&

      info.grade:&

    &
  );

}

function UI2(){ console.log(UI2 with comptued value); const {state, moduleComputed, syncBool} = useConcent({module:login, state:{show:true}}); return ( & {/* 當show為true的時候，當前組件的依賴是funnyName對應的依賴 name */} {state.show? &dep is name: {moduleComputed.funnyName}& : UI2 no deps now} & &

TAG:前端開發框架和庫 | 前端框架 | React |