В чому різниця Spread і Rest операторів?

Доволі часто можна зустріти таке питання на співбесідах. І його особливість в тому, що по суті, ми використовуємо ці оператори майже кожен день, але не всі знають, хто як обзивається. Наприклад, я на одному з перший інтерв'ю, коли в мене запитали це питання, говорила: “иии, ну цей, три точки, три точки”. Це максимум, що я могла з себе видавити. Тому давайте запам’ятовуємо раз і назавжди.

Давайте по простому, на прикладі масивів: Rest збирає дані в масив, spread, навпаки, розділяє дані масиву.

const [a, b, …rest] = [1, 2, 3, 4]; // a: 1, b: 2, rest: [3, 4]

В цьому випадку, ми зібрали 3, 4 в змінну rest і отримали масив.

const arr = [1,2,3];
const newArr = [...arr, 4]; // newArr: [1, 2, 3, 4]

А в цьому випадку масив arr розібрали на 1,2,3.

Тай таке.

Детальніше про ці два оператори, можете почитати тут: читати статтю

Там є дуужее багато прикладів, тому сподіваємось, буде наглядно і корисно 😉

#interview

GitHub Copilot

Ми вже десь вище писали за GitHub Copilot (а точніше тут).
Кароче, нам обом дали доступ!

І в нас є чудова новина: вони зараз почали активно відкривати доступи і тому ви також можете підписатись і швидко (амінь) поставити цей екстеншин. Посилання тут:

Відкрити сайт

Якщо коротко про наші враження, то Юрі він дуже зайшов і всім нашим знайомим. Починаєш щось писати - на тобі зразу готовий функціонал. Час дуже економить. Дійсно, розумна штука. Аж страшно!

А ось я як завжди. В мене зараз два активних проекта і в кожному я використовую Tailwind CSS (про мої враження від нього я напишу пізніше) + я працюю в Web Storm. І коли я включаю Copilot в мене середовище перестає підказувати tailwind і взагалі виключаються всі звичайні підказки (можливо якась фігня з версією Web Storm, як завжди). Тому я поки з ним не дуже подружилась. А шкода.

А ну да, Юрі ще досі цікаво, чи він не вчиться на нашому коді і чи не буде він його потім красти (наче комусь нада мій гавнокод).

Тому дуже чекаємо на ваші відгуки про цю круту штуку!

#experience

Всім привіт!

Нещодавно мені прилетіла задача, винюхати щось таке, на чому можна було б почати новий проект. Взагалі вибір був з двох - Next.js та Remix. Якщо хтось їх ще не зустрічав - це фреймворки для написання React додатків. Вони дозволяють рендерити сторінки на сервері, що робить сайт швидшим, та мають ще ряд переваг. Так як з Next.js я вже знайомий, головна ціль була зрозуміти чи буде Remix кращим вибором.

Сам фреймворк створений розробниками react-router. Також він дуже швидко білдиться, так як не використовує бандлерів, по типу, webpack чи rollup. Взагалі його творці повернулись до основ web-додатків. Самі запити відбуваються на стороні сервера, а клієнт робить їх за допомогою старих добрих форм. Якщо слідувати всім принципам фреймворку, то на клієнті можна обійтись і без підтримки Javascript. Але в свою чергу, це змушує вас робити все незручним (на мою думку) способом.

Моя думка сходиться з думкою автора відео нижче - Remix більше підходить для додатків з відображенням даних, наприклад, певної аналітики. Тому зараз моїм вибором став Next.js. В додачу виходу нової версії React, думаю, фреймворки теж отримають значні покращення.

В будь-якому випадку буде цікаво почути і вашу думку!

Дивитись відео

Читати документацію

#article

Cookies vs sessionStorage vs localStorage

Це питання не так часто задають на співбесідах, але дуже часто його можна почути на різних assessment review. Ну і плюс - це реально дуже корисно знати, що і як працює під капотом.

Як завжди, давайте, по простому.

Почнемо з cookies. Я думаю, вас також замахує, що коли заходиш на більшість сайтів, вас просять дозволити куки. Навіщо? Коли ви їх дозволяєте, на вашому пристрої додається маленький файл, в якому сайт записує дані про вас, які йому потрібні. Наприклад, цей сайт доступний у вільному доступі на 30 діб. Коли ви прийняли куки, сайт записав у файл дату, коли ви в перший раз заходили. І наступні рази, коли ви будете заходити на нього, він буде перевіряти по даті, чи ще не збігло тих 30 діб. Якщо так - ну всьо, допобачення.

localStorage - це місце, в якому ви можете зберігати собі дані у браузері за допомогою JavaScript. У кожного домена localStorage свій. А працювати з ним можна, як зі звичайним JSON об’єктом. І дані зберігаються навіть якщо закрити браузер.

А sessionStorage робить абсолютно те саме, але чиститься після закриття браузера.

Базу ми вам дали, а детальні можете почитати тут.

Читати статью

#interview

React v18.0

Ті хто слідкують за оновленнями знають що не так давно вийшла нова версія React.

Тому в кого є активний проект, саме час задуматись, про оновлення версії. А для тих кому цікаво, що ж там такого нового:

1. Concurrent mode. Це такий собі механізм який може одночасно готувати кілька рендерів для вашої компоненти.

2. Auto-batching. Колись, якщо ви в функції робили два setState - React робив два рендера, тепер ж він зробить тільки один.

3. Transitions. Тепер ви можете функцією або хуком помічати деякі задачі, які не є критичними. Як приклад це фільтрування користувачем даних. Поле для вводу має завжди швидко змінювати свій стан, а от саме фільтрування може зайняти якийсь час.

4. Ще кілька нових хуків, такі як useId та useDefferedValue.

Особисто я думаю, що оновлення це майже завжди дуже добре. Щодо цього конкретно, то було багато зроблено на покращення продуктивності. Не знаю тільки чи будуть активно використовуватись transition чи useId, useDefferedValue.

Читати статтю

#article

Tailwind

Обіцяла - виконую.
Тут ми вже писали про tailwind - читати пост

Тоді з ним працював Юра, я просто бачила одним оком документацію. Зараз я сама почала з ним працювати.

І ось, коротко про мої враження - в мене було два проекти з tailwind, зараз вже один)

На одному з проектів, який тільки недавно стартував, і ми вирішили його використовувати, врешті решт я його знесла і повернулась до звичайного scss. Чому? Там був важкий дизайн, багато деталей, і коли я наверстала пару секцій, було зрозуміло, що tailwind виглядає дуже брудно. А коли додала респонсів - то взагалі все було сумно. Стилі взагалі не читались. А я завжди дотримуюсь принципу: краще буде більше коду, ніж він буде зовсім не читабельним.

На іншому проекті, я не маю скільки влади, тому продовжую працювати на ньому. З плюсів, ми вирішили стилі писати відразу в html, тому це дуже економить час. Мінус: знову ж не читабельний код. А ще, якщо ви сподіваєтесь, що зможете переписати стилі, які вже існують, я вас засмучу - tailwind сортує стилі в своєму порядку. Я маю на увазі, що якщо у вас є стилі "text-white text-black", то не зрозуміло, який стиль візьметься, все залежить від tailwind. Для мене то було трохи критично, тому що в ui kit я завжди залишаю поле className, щоб за допомогою нього дописати або змінити трохи стилю в компоненті за необхідності.

Щоб вас не плутати. Tailwind можна писати прямо в html або за допомогою @apply використовувати в файлах стилів. Коли ви пишете в html, tailwind використовує свої класи. Наприклад, <p className="text-base text-white" /> - то у вас буде два класи: text-base і text-white. Якщо ви використовуєте @apply, то буде один клас, який ви створили і в нього будуть записуватись стилі.

Якщо коротко, то особисто для мене головний плюс tailwind - це економія часу (коли дійсно з ним розібратись), найголовніший мінус - нечитабельний код.

#experience

React performance

Нещодавно я готувався до інтерв‘ю по React Native. А ті, хто знайомі з ним, знають, що досить часто там може поставати питання продуктивності. Коли я читав одну статтю, першим реченням там було - "Все що впливає на продуктивність в React - впливає на неї і в React Native". Пропоную сьогодні зупинитися на React та виділити кілька тез, пов‘язаних з таким питанням.

Тези тут, освоєння за вами:

- Не створюйте функцій, об‘єктів у самому рендері компоненти. Винесіть це вище в константу.
- Навчіться користуватись хуками use(Memo|Callback|Ref), React.memo та PureComponent.
- Більшість HOC (функцій-обгорток, наприклад, connect від react-redux) зараз можна замінити хуками.
- Не забувайте, що setState (з хука useState) може встановлювати значення на основі попереднього, за допомогою переданої функції. Це часто допоможе позбутись, як мінімум, однієї залежності.

З кожним оновленням React стає все продуктивнішим. Але, здається, що і програмісти дедалі частіше знаходять способи написати поганий код.

Також хочу додати, що переоптимізовувати все теж недобре. Знайдіть золоту середину. Не треба оптимізовувати те, що і так добре працює. Витрачений час і можливе ускладнення коду не вартують цього.

#interview