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

привет всем, меня зовут Бека и фронтенд разработчик и у меня вопрос хотел на мабайл перейти с чего начать знаю: react js git html css bootstrap

привет всем, меня зовут Бека и фронтенд разработчик и у меня вопрос хотел на мабайл перейти с чего начать знаю: react js git html css bootstrap

https://styled-components.com/

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

весь этот хлам ломает оптимизацию стилей

откуда инфа? замерял?

возможно автор имеет введу оптимизацию ререндера с 18 реакта, хз. но если вы покажете мне приложение, где из-за инлайн стилей и их изменения сильно страдает перформанс — я прям руку вам пожму. до тех пор, увы, это миф

а что поменялось?

откуда инфа? замерял?

возможно автор имеет введу оптимизацию ререндера с 18 реакта, хз. но если вы покажете мне приложение, где из-за инлайн стилей и их изменения сильно страдает перформанс — я прям руку вам пожму. до тех пор, увы, это миф

https://stackoverflow.com/questions/54749558/avoid-rerender-in-react-caused-by-objects-literal-how-to-do-with-variables-in

вы сами писали про «кто-то что-то написал в 2021…», и тут же приводите ссылку, которой 4 с половиной года 🤷‍♂️ за это время многое изменилось в оптимизации реакта

в этом плане не изменилось

ну да, как раньше инлайн не влиял на перф, так и сейчас 🤷‍♂️

ну давай так, тебе к примеру 100 элементов приходит и ты их рендеришь компонентом, везде прописаны достаточно большие инлайн стили, в компоненте допустим 10 инлайн стилей, сколько объектов будет создано? я даже не про ререндер сейчас, а банально про память

если вы на полном серьёзе считаете, что в вашем случае надо начинать оптимизацию с меморизации инлайна, а не с того факта, что 100/1000 элементов по какой-то причине надо рендерить одновременно на экране, то мои полномочья всё. по поводу памяти, я уже говорил, самые дохлые телефоны за 5к рублей имеют по 2 гига оперы. самый большой инлайн будет ну 2 килобайта, ну пусть их будет 10 на компонет, 20 килобайт, ну пусть с какого-то тебе надо 1000 элементов одновременно зарендерить, это будет 20 мегабайт, это пщик. и повторю, в вашем кейсе начинать надо с вопроса, зачем рендерить 1000 элементов одновременно.

я тебе даю доводы, ты пишешь, это фигня надо смотреть другое лучше, и опять что телефон юзера все говно выдержит

и выше писал, что это не решает все проблемы, но один неправильно поставленный инлайн стиль может хорошо уронить производительность

https://blog.dbilgin.com/posts/are-inline-styles-bad/

не поленись поставь на свой проект WDYR и ты вероятно найдешь такие места

когда есть проблемы с рендером, я включаю wdyr, но опять же, вы приводите пример из официальной песочницы, где за каким-то хером 3к элементов рендерится. если нет явных проблем с перфом, я даже не пытаюсь ничего оптимизировать, это бесмысленная трата времени

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

на старых девайсах всё очень печально в любом случае, вне зависимости от вашей оптимизации. батарейка это прекрасно, экономить её надо, но в вашем случае вы сэкономите либо 0.000001% батарейки, т.к. ваше приложение на экране появляется на минуту в день, либо, если ваше приложение постоянно на экране, то пользователь очевидно сидит на зарядке.

ты хочешь сказать, что лучше говнокодить? все равно ничего не поможет?

я хочу сказать, что юзаю styled-components и стараюсь держать код адекватным, где надо — useMemo, где надо — useCallback. но так бывает не всегда, если нужно быстро запустить mvp и на руках нет ни тз ни дизайна, вполне можно набросать всё из говна и палок и оно будет работать. проверить модель и если всё работает, как задумано и оно нужно пользователю, потом уже делать красиво. я не говорю, что писать адекватный код это плохо, а говнокодить это хорошо. мы говорим о том, что инлайн стили не будут сильно влиять на перформанс. а если они по какой-то причине влияют да так, что это заметно — скорее всего дело не в них.

а я не говорил, что всегда сильно, что влияет и в редких кейсах сильно может просадить, в целом это влияет качество кода, многие MVP год пилят

если mvp пилится год, это уже долгострой, а не mvp ) про курочка по зёрнышку я понимаю о чём вы, но если мы говорим про react-native приложение на 20 экранов (что редко, обычно их меньше), если мы говорим о том, что понимаем как работает рендер/ререндер, если мы знаем о существовании wdyr и у нас есть здравый смысл, то очень сложно насобирать по 1% с разных участков кода, даже если по какой-то причине было принято писать стили инлайн. писать стили инлайн плохо, в этом я вас полностью поддерживаю, но если сильно хочется — ничего плохого не случится

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

мы не поставим точку, судя по всему ) вы продолжите настаивать, что влияет, я продолжу настаивать, что не настолько, чтобы это было заметно 🤷‍♂️

на старых девайсах всё очень печально в любом случае, вне зависимости от вашей оптимизации. батарейка это прекрасно, экономить её надо, но в вашем случае вы сэкономите либо 0.000001% батарейки, т.к. ваше приложение на экране появляется на минуту в день, либо, если ваше приложение постоянно на экране, то пользователь очевидно сидит на зарядке.

куда то пропал коммент писал что на старых девайсах все печально не в «в любом случае», лично оптимизировал с состояния «невозможно пользоваться» в «вполне сносно» и если приложение долго запущено то не значит что пользователь на зарядке - бред какой то

с точки зрения бизнеса, это бесполезный опыт ) нет смысла оплачивать разработчикам их время ради 1% пользователей на старых девайсах. за редким исключением, конечно. старые девайсы на старых андройдах могут просто неуметь в современную оптимизацию. на примере с gps, один и тот же код может по разному работать на разных версиях андройда. если брать китайские нонеймы, там gps может без причины просто не заводится, например )

с точки зрения бизнеса, это бесполезный опыт ) нет смысла оплачивать разработчикам их время ради 1% пользователей на старых девайсах. за редким исключением, конечно. старые девайсы на старых андройдах могут просто неуметь в современную оптимизацию. на примере с gps, один и тот же код может по разному работать на разных версиях андройда. если брать китайские нонеймы, там gps может без причины просто не заводится, например )

это уже бизнесу решать, и во многих странах типа африки там 99% таких девайсов, но разрабы в большинстве случаев даже не спрашивают бизнес и тупо говнокодят но даже на новых девайсах есть режим экономии батарейки, а за несколько процентов до выключения включается дополнительная экономия ресурсов и соответственно даже на новых девайсах можно добиться диких лагов

ты бизнесмен или разработчик? )

у меня телефон лагает ))) в режиме экономии, это заметно даже на анимациях открытия в телеге

ну т.е. проблема не в приложениях? я глянул расход батареи у себя — 40% это поиск сети 😄

телефон даже последней модели при низком заряде явно работает медленне, я не говорю про iphone 7, да даже X + не у всех новая батарея, это тоже влият, ты как бизнесмен должен это понимать

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

фронтеры, конечно, не могут влиять на бэк. я скорее о том, что не могу вспомнить приложений, которые бы тормозили именно ui, ну кроме очевидно кривых приложей, с вылетами итп. и при этом встретить приложение с тормозящим бэком — изи. меня как пользователя чаще именно это бесит, тормозов ui я, повторю, не помню. возможно они есть, но я их не замечаю. или из бесячего — явные ошибки логики, например, токен авторизации с коротким сроком жизни. приложение нефтьмагистрали этим грешило, заезжаешь на заправку раз в 2 недели и каждый раз надо авторизоваться через смс. и это тоже ошибки бэка, на которые фронтеры никак явно повлиять не могут. но будь приложение трижды оптимизированным, я как пользователь на авторизации потеряю больше времени, чем вся оптимизация 🤷‍♂️

а у вас какой опыт?

Apple приглашал на закрытое мероприятие ) за качественную прилу )

ну вот, а говорят, что react-native не может в тот же перформанс, что и натив. я долго на cordova писал и осознанного не переходил на rn, мне казалось, что это будет ограничивать возможности, как-то ближе к веб технологиям мы были, а если надо чего нативное — всегда можно написать свой модуль для кордовы.

А часто ли ты к примеру используешь reanimated? Может тебе кроме JS треда и правда ничего не нужно

не часто, разве что на каких-то pet проектах посмотреть, что нового появилось. с reanimated1 я почти не друэил, а второй не то, чтобы сильно надо следить за потоками как я понял, т.к. либа за тебя многое делает