Hook در ری اکت چیست و چرا باید از آن استفاده کنیم ؟

Hook در ری اکت چیست و چرا باید از آن استفاده کنیم ؟

Hook در ری اکت چیست و چرا باید از آن استفاده کنیم ؟

Whats React js Hooks ?

توسط : admin
اولین کاری که باید انجام دهید هر وقت می خواهید چیز جدیدی یاد بگیرید این است که از خودتان دو سوال بپرسید :چرا این چیز وجود دارد؟این مسئله چه مشکلاتی را حل می کند؟ با ما باشید تا به بررسی hooks در ری اکت بپردازیم .

 

اگر هیچ وقت پاسخ قانع کننده ای برای هر دو سوال بدست نیاوردید ، وقتی به سمت استفاده از ویژگی های جدید هجوم میبرید ، پایه و اساس کافی ندارید. این سؤالات به ویژه در رابطه با React Hooks مورد توجه است. زمان انتشار Hooks ، React محبوب ترین و زیبا ترین چارچوب فرانت اند در اکوسیستم JavaScript بود. با وجود تمجید موجود ، تیم React هنوز ساخت و انتشار هوکس را ضروری دانست. علی رغم تمجید و محبوبیت بالا ، تیم React تصمیم به صرف منابع با ارزش برای ساخت و انتشار هوک ها گرفت. برای درک بهتر پاسخ هر دو سؤال ، ابتدا باید نگاهی عمیق تر به چگونگی برنامه های React نوشته شده از نظر تاریخی داشته باشیم.

 

createClass

اگر به اندازه کافی  با React سرو کار داشته  بوده اید ، API React.createClass را به یاد خواهید آورد. این روش اصلی ساخت اجزای React بود. تمام اطلاعاتی که برای توصیف مؤلفه استفاده می کنید به عنوان شیء برای ایجاد Class منتقل می شوند.

const ReposGrid = React.createClass({
  getInitialState () {
    return {
      repos: [],
      loading: true
    }
  },
  componentDidMount () {
    this.updateRepos(this.props.id)
  },
  componentDidUpdate (prevProps) {
    if (prevProps.id !== this.props.id) {
      this.updateRepos(this.props.id)
    }
  },
  updateRepos (id) {
    this.setState({ loading: true })

    fetchRepos(id)
      .then((repos) => this.setState({
        repos,
        loading: false
      }))
  },
  render() {
    const { loading, repos } = this.state

    if (loading === true) {
      return <Loading />
    }

    return (
      <ul>
        {repos.map(({ name, handle, stars, url }) => (
          <li key={name}>
            <ul>
              <li><a href={url}>{name}</a></li>
              <li>@{handle}</li>
              <li>{stars} stars</li>
            </ul>
          </li>
        ))}
      </ul>
    )
  }
})

 

Run Code

createClass روشی ساده و مؤثر برای ایجاد مؤلفه های React بود. دلیل این که React در ابتدا از API createClass استفاده کرده بود به این دلیل بود که در آن زمان جاوا اسکریپت سیستم کلاس داخلی نداشت . البته این در نهایت تغییر کرد. با ES6 ، JavaScript کلمه کلیدی کلاس و به همراه آن یک روش بومی برای ایجاد کلاس در JavaScript را معرفی کرد. این مورد React را در وضعیت سختی قرار داد . یا با استفاده از createClass و مبارزه با پیشرفت JavaScript ادامه دهید و یا به خواست استاندارد EcmaScript تسلیم شوید و کلاسها را در آغوش بگیرید. همانطور که تاریخ نشان داده است ، آنها آینده را برگزیدند و مجبور به استفاده از کلاسها شدند .

 

React.Component

ما فهمیدیم که ما در کار طراحی سیستم کلاس نیستیم. ما فقط می خواهیم از هر روش و روش اصیل JavaScript برای ایجاد کلاس استفاده کنیم. - React v0.13.0 Release

 

React v0.13.0 API React.Component را معرفی کرد که به شما امکان می دهد اجزای React را از کلاسهای بومی JavaScript ایجاد کنید. این یک پیروزی بزرگ بود زیرا React را با استاندارد EcmaScript بهتر هماهنگ کرد.

 

class ReposGrid extends React.Component {
  constructor (props) {
    super(props)

    this.state = {
      repos: [],
      loading: true
    }

    this.updateRepos = this.updateRepos.bind(this)
  }
  componentDidMount () {
    this.updateRepos(this.props.id)
  }
  componentDidUpdate (prevProps) {
    if (prevProps.id !== this.props.id) {
      this.updateRepos(this.props.id)
    }
  }
  updateRepos (id) {
    this.setState({ loading: true })

    fetchRepos(id)
      .then((repos) => this.setState({
        repos,
        loading: false
      }))
  }
  render() {
    if (this.state.loading === true) {
      return <Loading />
    }

    return (
      <ul>
        {this.state.repos.map(({ name, handle, stars, url }) => (
          <li key={name}>
            <ul>
              <li><a href={url}>{name}</a></li>
              <li>@{handle}</li>
              <li>{stars} stars</li>
            </ul>
          </li>
        ))}
      </ul>
    )
  }
}

Run Code

اگرچه کامپوننتها یک گام روشن در جهت درست است ، ولی بدون ایراد نیز نبودند .

constructor :

با استفاده از کامپوننت های کلاس ، شما حالت مؤلفه را در داخل  سازنده به عنوان یک ویژگی state به عنوان (this) وارد می کنید. با این حال ، طبق مشخصات ECMAScript ، اگر شما یک زیر کلاس (در این مورد ، React.Component) را گسترش می دهید ، قبل از استفاده از این موضوع ، ابتدا باید super را کال کنید. به طور خاص ، هنگام استفاده از React ، شما همچنین باید به خاطر داشته باشید که props ها  را به super منتقل کنید.

 

constructor (props) {
    super(props) // 🤮

    ...
  }

 

Autobinding :

هنگام استفاده از createClass ، React به طور خودکار و جادویی تمام متد ها را به  this  متصل می کند. با React.Component ، اینگونه نبود. خیلی سریع ، توسعه دهندگان React  فهمیدند که نمی دانند این کلمه کلیدی چگونه کار می کند. به جای استفاده از روشهای فراخوانی که  "just worked" ، باید به یاد داشته باشید که روش های اتصال را در سازنده کلاس دارید. اگر این کار را نکردید ، خطای مشهور "Cannot read property setState of undefined" را دریافت کردند .

constructor (props) {
    ...

    this.updateRepos = this.updateRepos.bind(this) // 😭
  }

 

حالا می دانم چه فکر می کنید. اول ، این موضوعات بسیار سطحی است. مطمئناً فراخواندن (super(props و به خاطر سپردن روش های شما آزار دهنده است ، اما در اینجا هیچ چیز اساسی وجود ندارد. دوم ، اینها لزوماً حتی با React به اندازه طراحی کلاسهای JavaScript مشکل ندارند. هر دو نکته معتبر است. با این حال ، ما توسعه دهنده هستیم. حتی بیشتر از همه مسائل سطحی وقتی که 20+ بار در روز با آنها سر و کار دارید ناراحت کننده می شود. خوشبختانه برای ما ، اندکی پس از جابجایی از CreatClass به React.Component ، پیشنهاد Class Fields ارائه شد.

 

Class Fields :

Class Fields به شما امکان می دهد بدون نیاز به استفاده از سازنده ، خصوصیات نمونه را مستقیماً به عنوان یک ویژگی در کلاس اضافه کنید. آنچه برای ما معنی دارد این است که با Class Field ، هر دو موضوع "سطحی" ما که قبلاً در مورد آنها صحبت کردیم حل می شوند. ما دیگر نیازی به استفاده از سازنده برای تنظیم وضعیت اولیه مؤلفه نداریم و دیگر نیازی به اتصال به سازنده نداریم زیرا می توانیم از توابع Arrow  برای متدهای خود استفاده کنیم.

 

class ReposGrid extends React.Component {
  state = {
    repos: [],
    loading: true
  }
  componentDidMount () {
    this.updateRepos(this.props.id)
  }
  componentDidUpdate (prevProps) {
    if (prevProps.id !== this.props.id) {
      this.updateRepos(this.props.id)
    }
  }
  updateRepos = (id) => {
    this.setState({ loading: true })

    fetchRepos(id)
      .then((repos) => this.setState({
        repos,
        loading: false
      }))
  }
  render() {
    const { loading, repos } = this.state

    if (loading === true) {
      return <Loading />
    }

    return (
      <ul>
        {repos.map(({ name, handle, stars, url }) => (
          <li key={name}>
            <ul>
              <li><a href={url}>{name}</a></li>
              <li>@{handle}</li>
              <li>{stars} stars</li>
            </ul>
          </li>
        ))}
      </ul>
    )
  }
}

 

بنابراین اکنون همه چیز خوب است ، درست است؟ متاسفانه نه. حرکت از CreatClass به React.Component با برخی از معاملات صورت گرفت ، اما همانطور که دیدیم ، Class Fields مشکلات آنها را حل کرد. متأسفانه ، هنوز هم موضوعات عمیق تر (اما کمتر درباره آن صحبت شده است) با تمام نسخه های قبلی که دیده ایم وجود دارد.

 

کل ایده React این است که شما می توانید با تجزیه آن به اجزای جداگانه ای که می توانید با هم یکپارچه کنید ، پیچیدگی برنامه خود را مدیریت کنید. این چیزی است که React ، React را ایجاد می کند. با این وجود ، مسئله در مدل مؤلفه قرار ندارد ، بلکه در نحوه اجرای مدل مؤلفه است.

 

منطق چندگانه :

از لحاظ تاریخی ، نحوه ساختن مؤلفه های React ما با چرخه عمر این مؤلفه همراه شده است. این شکاف به طور طبیعی ما را وادار می کند تا منطق مربوط را در کل مؤلفه پیاده کنیم. ما می توانیم به روشنی این را در مثال ReposGrid که از آن استفاده کرده ایم ببینیم. ما برای دستیابی به همان چیز به سه روش جداگانه (مؤلفهDidMount ، مؤلفهDidUpdate ، و به روز رسانیRepos) نیاز داریم - با استفاده از props.id ، repos را همگام نگه دارید.

 

componentDidMount () {
    this.updateRepos(this.props.id)
  }
  componentDidUpdate (prevProps) {
    if (prevProps.id !== this.props.id) {
      this.updateRepos(this.props.id)
    }
  }
  updateRepos = (id) => {
    this.setState({ loading: true })

    fetchRepos(id)
      .then((repos) => this.setState({
        repos,
        loading: false
      }))
  }

 

برای برطرف کردن این مسئله ، به روشی که بتوانیم از مشکلات جانبی در اجزای React استفاده کنیم ، نیاز به یک الگوی کاملاً جدید داریم.

 

منطق غیر بصری :

وقتی در مورد React به composition  فکر می کنید ، شانس این را  دارید که از دید composition UI فکر کنید. این طبیعی است زیرا ری اکت در اینکار عالی است .

 

view = fn(state)

از نظر واقعی ، چیزی بیش از لایه UI برای ساختن یک برنامه وجود ندارد. نیازی به تهیه و استفاده مجدد از منطق غیر تصویری غیر معمول نیست. با این حال ، به دلیل اینکه ReI رابط کاربر را به یک مؤلفه وصل کنید ، این مشکل است. از نظر تاریخی ، React پاسخ خوبی برای این امر نداده است.

 

با استفاده از مثال خود ، می گویند ما نیاز به ایجاد مؤلفه دیگری داشتیم که به حالت repos نیز احتیاج داشت. در حال حاضر ، این حالت و منطق رسیدگی به آن در داخل مؤلفه ReposGrid وجود دارد . چگونه می توانیم به این موضوع نزدیک شویم؟ خوب ، ساده ترین روش این است که همه منطق ها را برای واگذاری و استفاده از repos های ما کپی کرده و آنرا در قسمت جدید قرار دهید. وسوسه کننده ، اما آره. یک رویکرد دقیق تر ایجاد یکHigher-Order Component خواهد بود که کلیه منطق مشترک را محاصره می کند و بارگیری و دریافت Props ها  را  برای اجزای مورد نیاز خود منتقل می کند.

 

function withRepos (Component) {
  return class WithRepos extends React.Component {
    state = {
      repos: [],
      loading: true
    }
    componentDidMount () {
      this.updateRepos(this.props.id)
    }
    componentDidUpdate (prevProps) {
      if (prevProps.id !== this.props.id) {
        this.updateRepos(this.props.id)
      }
    }
    updateRepos = (id) => {
      this.setState({ loading: true })

      fetchRepos(id)
        .then((repos) => this.setState({
          repos,
          loading: false
        }))
    }
    render () {
      return (
        <Component
          {...this.props}
          {...this.state}
        />
      )
    }
  }
}

 

حال هر زمان که هر عنصر در برنامه ما به repos (یا بارگیری) نیاز داشته باشد ، می توانستیم آن را در withRepos HOC قرار دهیم .

 

// ReposGrid.js
function ReposGrid ({ loading, repos }) {
  ...
}

export default withRepos(ReposGrid)
// Profile.js
function Profile ({ loading, repos }) {
  ...
}

export default withRepos(Profile)

 

این اثر و به لحاظ تاریخی (همراه با Render Props) راه حل پیشنهادی برای به اشتراک گذاشتن منطق غیر بصری بوده است. با این حال ، هر دو این مدل الگوهای جانبی دارند.

 

اول ، اگر با آنها آشنا نیستید (و حتی هنگامی که هستید) ، مغز شما با منطق می تواند کمی پیروز شود. با withRepos HOC ما ، تابعی را داریم که جزء نهایی ارائه شده را به عنوان اولین استدلال در نظر می گیرد ، اما یک جزء کلاس جدید را که در منطق ما وجود دارد ، برمی گرداند. چه فرآیندی پیچیده ای .!

بعد، اگر ما بیش از یک HOC ما  نیاز داشته باشیم . همانطور که می توانید تصور کنید ، کمی کنترل از دست شما خارج می شود.

 

export default withHover(
  withTheme(
    withAuth(
      withRepos(Profile)
    )
  )
)

 

بدتر از آن چیزی است که در نهایت ارائه می شود. HOCs (و الگوهای مشابه) شما را مجبور به بازسازی و پیچیدن اجزای خود می کند. این در نهایت می تواند منجر به "جهنم بسته بندی شده" شود که دوباره ، پیروی از آن را سخت تر می کند.

 

<WithHover>
  <WithTheme hovering={false}>
    <WithAuth hovering={false} theme='dark'>
      <WithRepos hovering={false} theme='dark' authed={true}>
        <Profile 
          id='JavaScript'
          loading={true} 
          repos={[]}
          authed={true}
          theme='dark'
          hovering={false}
        />
      </WithRepos>
    </WithAuth>
  <WithTheme>
</WithHover>

 

وضعیت فعلی ما :

اکنون در این نقطه هستیم .

React بسیار محبوب است.

ما از کلاس هایی برای اجزای React استفاده می کنیم و این همان چیزی است که در آن زمان بیشترین حس را ایجاد کرده است.

فراخوانی با (super(props آزار دهنده است.

هیچ کس نمی داند this  چگونه کار می کند.

باشه ، آرام باش من می دانم که شما می دانید که this  چگونه کار می کند، اما این برای برخی موانع غیر ضروری است.

ساماندهی اجزای ما با روش های چرخه عمر ما را وادار می کند تا منطق مربوط به آن را در همه اجزای خود پیاده کنیم.

React هیچ چیز ابتکاری خوبی برای به اشتراک گذاشتن منطق غیر بصری ندارد.

اکنون ما به یک API کامپوننت جدید نیاز داریم که در عین حال ساده ، کامپوزیت ، انعطاف پذیر و قابل تمدید ، همه این مشکلات را حل کند. این کار کاملاً  انجام شده  و  به نوعی تیم React آن را بیرون کشیده است .

 

React Hooks :

از React v0.14.0 ، ما دو راه برای ایجاد مؤلفه ها - کلاس ها یا توابع داریم. تفاوت در این بود که اگر مؤلفه ما state داشته باشد یا به استفاده از یک روش چرخه عمر نیاز داشته باشد ، مجبور بودیم از یک کلاس استفاده کنیم. در غیر این صورت ، اگر آن کامپوننت فقط پذیرفته شد و برخی از رابط کاربر را ارائه داد ، ما می توانستیم از یک تابع بدون state استفاده کنیم.

 

حالا ، اگر اینطور نبود چه می شود اگر به جای اینکه مجبور به استفاده از یک کلاس باشیم ، همیشه می توانستیم از  تابع استفاده کنیم.

مطمئناً ما باید راهی برای افزودن توانایی اجزای کاربردی برای داشتن روش های حالت lifecycle methods پیدا کنیم ، اما با فرض اینکه این کار را کردیم ، چه فایده ای خواهیم برد؟

 

خوب ، ما دیگر نیازی به فراخوانی با (super(props نخواهیم داشت ، دیگر نیازی به نگرانی در مورد اتصال روش های خود با کلمه کلیدی this نخواهیم بود و دیگر نیازی به استفاده از Class Fields نخواهیم داشت. در اصل ، تمام موضوعات "سطحی" که قبلاً در مورد آنها صحبت کردیم از بین می رود.

اکنون ، مسائل سخت تر.

 

state

Lifecycle methods

منطق غیر بصری

 

State :

از آنجا که ما دیگر از کلاسها یا این موارد استفاده نمی کنیم ، به روش جدیدی برای اضافه کردن و مدیریت وضعیت در داخل اجزای خود نیاز داریم. از React v16.8.0 ، React این روش جدید را با استفاده از روش useState به ما می دهد.

 

useState اولین  hook از بسیاری از "Hook" ها است که در این دوره مشاهده خواهید کرد. بگذارید بقیه این پست به عنوان یک مقدمه نرم ارائه شود. ما در بخش های بعدی بسیار عمیق تر به موارد دیگر hook خواهیم پرداخت .

 

useState یک آرگومان واحد را می گیرد ، مقدار اولیه state. آنچه باز می گردد ، آرایه ای است که مورد اول آن قطعه state است و مورد دوم تابعی برای به روزرسانی آن state .

 

const loadingTuple = React.useState(true)
const loading = loadingTuple[0]
const setLoading = loadingTuple[1]

...

loading // true
setLoading(false)
loading // false

 

همانطور که مشاهده می کنید ، گرفتن هر مورد در آرایه به صورت جداگانه بهترین تجربه توسعه دهنده نیست. این فقط برای نشان دادن چگونگی بازگرداندن useState آرایه است. به طور معمول ، شما برای گرفتن مقادیر در یک خط از Array Destructionuring استفاده می کنید.

 

// const loadingTuple = React.useState(true)
// const loading = loadingTuple[0]
// const setLoading = loadingTuple[1]

const [ loading, setLoading ] = React.useState(true) // 👌

 

اکنون بیایید مؤلفه ReposGrid خود را با دانش جدید یافته شده ما در مورد UseState Hook به روز کنیم.

 

function ReposGrid ({ id }) {
  const [ repos, setRepos ] = React.useState([])
  const [ loading, setLoading ] = React.useState(true)

  if (loading === true) {
    return <Loading />
  }

  return (
    <ul>
      {repos.map(({ name, handle, stars, url }) => (
        <li key={name}>
          <ul>
            <li><a href={url}>{name}</a></li>
            <li>@{handle}</li>
            <li>{stars} stars</li>
          </ul>
        </li>
      ))}
    </ul>
  )
}

 

 

Lifecycle methods یا چرخه حیات کامپوننتها :

در اینجا چیزی است که ممکن است شما را ناراحت کند (یا  شاید خوشحال کند؟). من هنگام استفاده از React Hooks ، می خواهم همه چیزهایی را که می دانید در مورد روش های سنتی  چرخه عمر و همچنین آن روش تفکر بردارید و آن را فراموش کنید. ما قبلاً مشکل تفکر را از نظر چرخه عمر یک مؤلفه مشاهده کرده ایم - "این تقسیم چرخه عمر به طور طبیعی ما را وادار می کند تا منطق مربوط به آن را در سراسر مؤلفه پیاده کنیم." در عوض ، با دید هماهنگی فکر کنید.

به هر زمانی فکر کنید که از یک رویداد چرخه عمر استفاده کرده اید. این که آیا برای تنظیم وضعیت اولیه مؤلفه ، واکشی داده ها ، به روزرسانی DOM ، هر چیزی - هدف نهایی همیشه هماهنگ سازی بود. به طور معمول ، همگام سازی هر چیزی در خارج از سرزمین React (درخواست API ، DOM و غیره) با چیزی در داخل React land (حالت جزء) یا برعکس.

 

هنگامی که به جای وقایع  چرخه عمر از لحاظ هماهنگ سازی فکر می کنیم ، به ما امکان می دهد تا قطعات منطقی مرتبط را با هم جمع کنیم. برای انجام این کار ، React به ما هوک دیگری می دهد به نام useEffect ارائه داده است .

 

 useEffect به شما امکان می دهد عوارض جانبی را در مؤلفه های عملکرد انجام دهید. دو آرگومان ، یک تابع و یک آرایه اختیاری طول می کشد. این تابع تعریف می کند که کدام یک از عوارض جانبی برای اجرا هستند و آرایه (اختیاری) تعیین می کند که چه زمانی "دوباره همگام سازی" (یا دوباره اجرا) اثر را انجام می دهند.

React.useEffect(() => {
  document.title = `Hello, ${username}`
}, [username])

در کد بالا ، تابع منتقل شده به useEffect در هر زمان با تغییر نام کاربری اجرا می شود. بنابراین ، همگام سازی عنوان سند با هر سلام ، نام کاربر تغییر میکند .

 

حال ، چگونه می توانیم از UseEffect هوک در داخل کد خود استفاده کنیم تا بتوانیم با استفاده از درخواست API fetchRepos ، یکپارچه سازی را تقسیم بندی کنیم؟

 

function ReposGrid ({ id }) {
  const [ repos, setRepos ] = React.useState([])
  const [ loading, setLoading ] = React.useState(true)

  React.useEffect(() => {
    setLoading(true)

    fetchRepos(id)
      .then((repos) => {
        setRepos(repos)
        setLoading(false)
      })
  }, [id])

  if (loading === true) {
    return <Loading />
  }

  return (
    <ul>
      {repos.map(({ name, handle, stars, url }) => (
        <li key={name}>
          <ul>
            <li><a href={url}>{name}</a></li>
            <li>@{handle}</li>
            <li>{stars} stars</li>
          </ul>
        </li>
      ))}
    </ul>
  )
}

 

خیلی نرم و زیبا ، درست است؟ ما با موفقیت از React خلاص شدیم. مؤلفه ، سازنده ، فوق العاده ، و مهمتر از همه ، دیگر منطق تأثیرگذاری ما در کل این قطعه پیاده نشده است (و تکثیر شده است).

 

Sharing non-visual logic یا منطق غیر بصری :

پیش از این ذکر کردیم که دلیل واکنش React در به اشتراک گذاشتن منطق غیر بصری پاسخ خوبی ندارد ، زیرا "UI را به یک مؤلفه تغییر میدهد." این امر منجر به الگوهای پیچیده ای مانند اجزای مرتبه بالاتر یا props Render می شود. همانطور که احتمالاً تاکنون حدس می زنید ، هوکس ها نیز پاسخی برای این موضوع دارند. با این حال ، احتمالاً این چیزی نیست که شما فکر می کنید. هیچ hook داخلی برای اشتراک منطق غیر بصری وجود ندارد ، در عوض ، می توانید hook های دلخواه خود را بسازید که از هر رابط کاربری جدا شده اند.

 

ما می توانیم این کار را با ایجاد کاربری سفارشی Repos Hook خود مشاهده کنیم. این هوک از شناسه repos هایی که می خواهیم واکشی کنیم ، می گیرد و (برای چسباندن به یک API مشابه) یک آرایه را برمی گرداند که اولین مورد حالت بارگذاری و مورد دوم حالت repos است.

function useRepos (id) {
  const [ repos, setRepos ] = React.useState([])
  const [ loading, setLoading ] = React.useState(true)

  React.useEffect(() => {
    setLoading(true)

    fetchRepos(id)
      .then((repos) => {
        setRepos(repos)
        setLoading(false)
      })
  }, [id])

  return [ loading, repos ]
}

 

خوب است هر منطقی که مربوط به واگذاری repos ما باشد می تواند در داخل این هوک سفارشی خلاصه شود. اکنون ، صرف نظر از کدام مؤلفه ای که در آن قرار داریم و حتی منطق غیر بصری آن ، هر زمان که به داده های مربوط به repos نیاز داشته باشیم ، می توانیم از Repos custom Hook استفاده کنیم.

function ReposGrid ({ id }) {
  const [ loading, repos ] = useRepos(id)

  ...
}

 

function Profile ({ user }) {
  const [ loading, repos ] = useRepos(user.id)

  ...
}

 

 

نکته اصلی بازاریابی برای هوک ها این است که شما می توانید از اجزای عملکردی در سفشفث استفاده کنید. در واقعیت ، هوکس ها خیلی بیشتر از اینها هستند. آنها در مورد استفاده مجدد از کد ، ترکیب و پیش فرض بهتر هستند. برای هوک ها چیزهای بیشتری وجود دارد که ما هنوز باید آنها را پوشش دهیم ، اما اکنون که می دانید چرا آنها وجود دارند ، ما یک پایه محکم برای ساختن آن داریم.

 

 

 

نظرات :

در عرض چند دقیقه برای ایجاد حساب

کاربری خود اقدام کنید


اکنون حساب کاربری خود را ایجاد کنید!


ایجاد حساب کاربری

با ثبت نام در نیلوتک از آخرین بروز رسانی های آموزش ها و مقالات سایت مطلع شوید