Scroll to top

Сьогодні в чат прилетіло круте питання: як після рендеру контенту (після так би мовити "переходу" з одної сторінки на іншу) перенести користувача на початок сторінки? Адже якщо залишити все як є, користувач опиняється на тому ж місці, на якому була відкрита попередня сторінка. Наприклад, у вас є футер з лінками. І після того як ви натиснули на будь-який лінк, у вас відкривається нова сторінка з фокусом внизу, де і був футер (якщо це звичайно посилання на сторінку вашого сайту). Проект на React і використовується React Router.

Це досить поширена проблема, тому ділимось досить хорошим рішенням - читати статтю. АЛЕ це рішення підходить лише для тих, хто використовує React Router п’ятої версії. А для тих хто любить тестувати щось нове - ось бета рішення для шостої версії React Router - читати статтю.

Бажаємо вам продуктивного тижня! 💛

#article

Що таке one-liner?

Чим менше коду - тим краще

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

Також додаємо один від себе, який досить часто використовуємо в роботі:

const fullName = (...names: string[]) => names.filter(Boolean).join(' ');

А своїм корисним one-liner діліться з нами в коментарях!

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

#article

12-factor application

Коли ви розробляєте додаток, ви приймаєте різні рішення щодо його архітектури та стилю. Для покращення якості проектів часто створюють різні набори принципів, практик та правил, або, якщо коротко, методології. Один сильно технічний замовник з немалим досвідом розповів мені про одну з них, яку ми потім намагались застосувати для нашого проекту.

Застосунок 12-ти факторів - це методологія для створення веб-застосунків, яка описує фактори, що впливають на масштабованість, переносимість та можливість розгортання на хмарних платформах, або просто ті, які зможуть значно полегшити вам життя та розробку.

Давайте глянемо на декілька з них:

- оголошення та ізоляція залежностей - всі залежності вашого застосунку мають бути описані (package.json, Pipfile) для того, щоб можна було з легкістю зрозуміти, що потрібно встановити, та мають бути ізольованими (node_modules/, virtualenv).
- конфігурація - налаштування, що можуть змінюватись для різних середовищ, мають перебувати саме в змінних оточення. Щоб було простіше, згадайте .env файли, process.env або os.getenv.
- dev/prod паритет - застосунок проектується для Continuous Deployment, отже потрібно мінімізувати різницю між dev та prod середовищами. Завдяки цьому, ви зможете побачити однакову поведінку при розробці та в релізі, тому зможете релізитись хоч щогодини.

Як не дивно, там є ще 9 правил (бо всього 12), тому переходьте за посиланням і дивіться повний опис.

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

Звісно, буває нелегко дотримуватись багатьох правил. Дану методологію, наприклад, часто критикують через її заточеність під Heroku (саме розробники платформи Heroku описали правила 12-factor додатку).

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

#article

❗️До кінця розіграшу залишилось 11 днів - доєднатись

SemVer + CHANGELOG

Чи помічали ви коли-небудь "нотатки", коли оновлювали додаток в App Store чи Play Market? Часто там можна побачити щось таке, як "Bug Fixes", або ж зміни, що були додані в новій версії, описані людською мовою. Такі деталі зберігаються в файлику CHANGELOG, в якому від версії до версії описано, що ж було додано, змінено чи видалено.

До речі, якщо говорити про самі версії, там зазвичай є три числа, записаних через крапку. Коли і як їх потрібно змінювати? Тут рекомендуємо коротко переглянути такий підхід як Семантичне Версіонування (SemVer).

Прикріпляємо для вас документації/статті українською мовою:

Читати про CHANGELOG
Читати про SemVer

#article

Advanced VS Code Shortcuts

Працюєш у VS Code? Маємо для вас дещо корисне! 🤩

Ні для кого не секрет, що робота за допомогою комбінацій клавіш на клавіатурі набагато швидша, ніж за допомогою миші.

Тому знайшли 2 статті (2 частини), де показано на детальних прикладах використання крутих шорткатів. Деякі для нас добре відомі і ми постійно їх використовуємо, а деякі ми побачили вперше, але вже активно практикуємо в роботі!

👉 Читати частину 1
👉 Читати частину 2

Зберігайте і, найголовніше, використовуйте! 💛

#article

APIs for your project

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

Хочемо поділитися з вами статтею з списком відкритих API, з яких ви можете почерпнути трохи натхнення та знайти ідею для власного проекту.

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

#article

ChatGPT Extensions

Всі ми вже чули, що минулого тижня ChatGPT став доступним в Україні! 🎉

Сподіваємось, ви вже встигли з ним добре ознайомитись і попробувати використати всі його можливості.

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

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

#article

http.dev 💌

Дуже велика частина мережевих запитів у сучасних застосунках виконується за протоколом HTTP. Ділимося з вами сайтом-шпаргалкою, де ви можете підглянути інформацію щодо самого протоколу, статусів, хедерів та методів.

👉 Відкрити посилання

А щоб було трішки веселіше, ділимося з вами ресурсами, на яких ви зможете знайти різні HTTP-статуси ілюстровані картинками з котиками та собачками 🐱🐶 Вони ну прям дууужеее смішні!

👉 HTTP Cat
👉 HTTP Dog
👉 HTTP Dog 2

#article

CLI Guidlines 🦮

Якщо ви будуєте свою CLI, то вам теж треба продумати хороший UX. Щоб користувачам було просто і зручно користуватись вашим застосунком, необхідно дотримуватись певних стандартів та правил. Сьогодні ділимось з вами списком настанов та найкращих практик щодо побудови свого CLI.

👉 Відкрити посилання

#article

Як додати перевірку свого коду на GitHub Actions? 🌩️

Припустимо, що ваш застосунок написаний на JavaScript. Якщо ж ви використовуєте іншу мову, можете теж використовувати цей підхід, потрібно буде лише замінити скрипт перевірки. Отож, уявіть себе девопсом yaml-розробником і почнімо.

Власне, перед початком налаштовування GitHub Action ми зазвичай робимо ще одну річ - додаємо власний скрипт в package.json, який трохи спростить використання і запуск команди. Найчастіше ми додаємо там перевірку форматування через prettier та статичний аналіз з допомогою eslint та tsc. Виглядає це приблизно отак:

"scripts": {
  "check": "prettier --check . && eslint . && tsc --noEmit"
}

Для початку в корені свого проєкту потрібно створити директорію .github, всередині якої ще одну з назвою workflows. Тут ми і будемо розміщувати свій файл конфігурації. Створимо цей файл і дамо йому назву check.yml.

Якщо ви не знайомі з YAML, це як JSON на Python. Головне слідкуйте за відступами.

Почнемо з імені, додайте у файл:

name: Run web check

Тепер треба прописати, коли ж запускати цей екшн. Дозволимо запускати його ручками та будемо автоматично запускати його при будь-якому пуші.

on:
  workflow_dispatch: # вручну на GitHub
  push: # при push в репозиторій

Почнімо ж нарешті описувати кроки перевірок. Створимо job з іменем check. Запускати це все ми будемо на останній ubuntu, а першим кроком додамо клонування вашого репозиторію.

jobs:
  check:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

Отож, на цій машині вже є наш репозиторій. А на ubuntu одразу встановлений Node.js? Не знаємо, тому краще встановити його. На всяк випадок вкажемо версію Node.js. А ще, GitHub сам вміє кешувати модулі Node.js, тому скажемо йому робити це також.

      - name: Setup Node.js 20
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

Ну тепер Node.js точно є, але немає node_modules. Ну це вже дуже просто, всі ми знаємо потрібну команду.

      - name: Install dependencies
        run: npm install

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

      - name: Run check
        run: npm run check

Усе це разом, а також з невеличким налаштуванням pnpm, concurrency, strategy та монорепо (Node.js застосунок знаходиться не в корені проєкту), можна знайти за посиланням нижче.
👉 Відкрити файл

Щоб більше почитати про GitHub Actions використовуйте посилання внизу. А від @MatiGreen чекаємо повідомлення про те, як зробити те саме на GitLab 😉
👉 Відкрити посилання

#article