Search
Write a publication
Pull to refresh
0
0
Send message

Вообще то не понял.

Сразу скажу, те "кастомные классы" что вы упомянули не позволяют работать с состоянием компонентов, они просто предоставляют интерфейс для взаимодействия с внешними зависимостями.

Я не так знаком с классовыми компонентами в реакте как вы и хотел бы узнать, как выделить логику работающую с состоянием в отдельные модули по аналогии с кастомными хуками.

Возможно в классовых компонентах это делать так же просто как и в хуках? Можете дать ссылку или привести пример, как это обычно делается?

Vanilla предполагает написание прикладного кода без фреймворка.

Очевидно что да. Просто если нужно вот пик возмножного быстродействия (а я именно в таком контексте первый раз упомянул ваниллу). То ванилла позволяет создать приложение как минимум не медленнее самого быстрого существующего фреймворка. Получится ли это у разработчика - зависит от его квалификации.

Цитируя свое первое сообщение "хуки не идеальны"

Опять цитирую его же:

"У хуков кстати есть классная возможность - можно писать свои кастомные хуки и удобно переиспользовать их где хочется. Не уверен, что это так же удобно делать на классах. "

Подытожим - я просто указал на то что у хуков как ни странно есть не только недостатки, но и вполне удобный (и возможно уникальный для функциональных компонентов) функционал.

А являются ли хуки преимуществом функции или нет я даже обсуждать не хочу, это тема для холивара

На тему же бенчмарка и "все просто", мне вот просто удивительно, а что, фреймворки на каком то эльфийском написаны а не на vanillajs?

Не буду спорить насчет бенчмарка, хотя это выглядит так же странно как java обогнавшая в производительности ассемблер.

Насчет перескочили - мы изначально обсуждали компоненты реакт и как бы хуки это часть функциональных компонентов, в том числе в вашей первой ссылке они упоминаются. Кстати вы почему то решили что кастомные хуки можно заменить "кастомными классами", хотя это дополняющие друг друга вещи, а не замена.
На тему крит. проблем в видео - у меня и на работе своих проблем хватает, к чему мне ломать голову над чужими?

Ну так тот же самый класс можно использовать и с функциональными компонентами, никто же не мешает. Я частенько таким и пользуюсь, добавляя внешние зависимости для приложения.
Мы же вроде о преимуществе классов в роли компонентов react? Или я что то перепутал читая статью по ссылке?
А на тему хайпа и Solid/Svelte/React - по мне так фундаментальная смена подхода к написанию уже достаточно быстрого приложения (см выше мои аргументы), для оптимизации его производительности выглядит неубедительно
Вы кстати забыли про упомянутую мной ванилу - там скорость и возвращение к корням, вы же не посчитаете эту рекомендацию очередным происком хайперов?
Кстати потыкал по ссылкам, не уверен насчет вас, но я писал приложения и на Svelte и на Solidjs и там порой такая нелогичная фигня что мозг кипит. Но пару небольших приложений на Solidjs я все же сделал, размер конечного бандла многое окупает.

Да, хуки не идеальны, колбэки боль и лишнии ререндеры случаются. С другой стороны при использовании бест практис и аккуратной реализации длинных листингов проблем с дерградацией производительности из за ререндеров обычно не бывает даже на больших страницах, даже на бюджетных телефонах (это из моего опыта, у вас может быть другой).
Если же проблемы все же есть, проблемные места обычно можно дополнительно оптимизировать с useReducer, useMemo, useRef и т.д.
Я как то привык к тому как выглядят компоненты в функциональном стиле и на фоне вышеприведенных аргументов на классы переучиваться неохота.
У хуков кстати есть классная возможность - можно писать свои кастомные хуки и удобно переиспользовать их где хочется. Не уверен, что это так же удобно делать на классах.
А если вот хочется сделать очень быстрое приложение, мало весящее, быстро рендерящее - тогда имеет смысл смотреть на альтернативы реакту вроде SolidJS (ну или прям на ваниллу)

Я пишу фронтенд в основном на react и typescript. И да, в основном весь код состоит из функций. Но классы очень удобны в отдельных случаях.

Например недавно я сделал небольшой виджет для сайта, где ООП вписалось как родное.
Получилось 2 класса

class Service implements ServiceType {
  constructor(appId: string)
  async getSettings()
  async sendForm(payload: FormPayload)
  terminateAllRequests()
}

class Widget {
  constructor(service: ServiceType)
  render(container: HTMLElement)
  destroy()
}

// используется примерно как
const container = document.createElement('div')
document.body.appendChild(container)

const widget = new Widget(new Service('123'))
widget.render(container)

// ... когда виджет больше не нужен, деинициализиуем его
widget.destroy()
container.remove()

Widget рендерит внутри указанного элемента небольшое Preact приложение и через контекст предоставляет доступ к Service всем компонентам.
Я не слишком люблю наследование (хотя в отдельных случаях оно удобно), да и большие иерархии классов для меня выглядят подозрительно (для такого должна быть хорошая причина и довольно часто это поддержка легаси кода). Но как минимум если классы довольно просты и четко разделяют ответственность - это удобно.

Сейчас существует вполне вычисляемая граница, за которой скорость убегания объектов от наблюдателя превышает световую и объекты за который мы никогда не сможем наблюдать.
Что там - за этой границей - никто не знает, но некоторые наблюдения вроде темного потока, который допускают существование большой массы за пределами этой границы.

Вообще мы пока на стадии цивилизации которая толком не использует даже энергию нашей планеты. По классификации разных типов цивилизаций, если мы достигнем развития допускающего использование энергий сопоставимых энергией солнечно системы.. Того теоретические наработки вроде двигателя Альбукерке может и смогут реализовать, а это означает возможность движения быстрее скорости света.

И тогда мы как минимум узнаем что там за этой границей текущей вселенной.

А может еще раньше докажем что измерений больше 4х и таки научимся в них как минимум заглядывать

Все же AbortController немного по другому действует, если посмотрите в консоли браузера - controller.abort() отменяет запрос к бэкэнду, а то время как реализация с флагом просто игнорирует его. Я к тому что использование AbortController может позволить бэку более эффективно использовать свои ресурсы (ну и траффик между фронтом и бэком немного сэкономим). Ну может это было очевидно, просто я недавно как раз решал похожую задачу с реализацией автокомплита в инпуте и там это было важно

Попробуйте вместо использования флага cancelled использовать AbortController https://developer.mozilla.org/en-US/docs/Web/API/AbortController

Information

Rating
Does not participate
Registered
Activity

Specialization

Fullstack Developer, Software Architect
Lead
From 5,000 $
TypeScript
React
Web development
CSS
JavaScript
NextJS
GraphQL
Node.js