Розробка веб-сайтів для iPhone X

З коробки Safari прекрасно відображає ваші існуючі веб-сайти по відтворенню від краю до краю нового iPhone X. Вміст автоматично вставляється в безпечну область екрана, щоб він не затуманився за округлими кутами або корпусом датчика пристрою.

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

Інші сторінки, особливо ті, які розроблені з широкоширотними горизонтальними навігаційними панелями, такі як сторінка нижче, можуть додатково перейти далі, щоб повністю використовувати можливості нового дисплея. Правила iPhone X Human Interface містять деякі загальні принципи проектування, про які слід пам’ятати, і в документі UIKit обговорюються конкретні механізми, якими можуть користуватися оригінальні додатки, щоб гарантувати, що вони добре виглядають. На вашому веб-сайті можна скористатись кількома подібними новими частинами API WebKit, представленими в iOS 11, щоб максимально використовувати переваги меж-суті екрана.

Використання всього екрана

Перша нова функція – це розширення існуючого viewport метатегу viewport-fit, що викликається , що забезпечує контроль над вставкою поведінки. viewport-fit доступний в iOS 11.

Значення за замовчуванням viewport-fit є auto, що призводить до автоматичного вставлення поведінки, наведене вище. Щоб вимкнути цю поведінку та примусити сторінку вирівняти повний розмір екрана, ви можете встановити viewport-fit її cover. Після цього наш viewport метатег виглядає так:

<meta name='viewport' content='initial-scale=1, viewport-fit=cover'>

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

Повага до безпечних районів

Наступний крок, спрямований на те, щоб знову зробити нашу сторінку доступною після прийняття, viewport-fit=cover полягає у вибірковому застосуванні елементів, які містять важливий вміст, для того, щоб вони не затушували форму екрана. Це призведе до появи сторінки, яка повною мірою сприяє збільшенню екранної нерухомості на iPhone X при динамічному настроюванні, щоб уникнути кутів, корпусу датчиків та індикатора доступу до головного екрана.

Для досягнення цієї мети в WebKit прошивки 11 включає в себе нову функцію CSS, constant() і набір з чотирьох попередньо визначених констант, safe-area-inset-left, safe-area-inset-right, safe-area-inset-top, і safe-area-inset-bottom. У сукупності вони дозволяють деклараціям стилів посилання на поточний розмір вбудованих безпечних зон з кожної сторони.

Робоча група CSS нещодавно вирішила додати цю функцію, але з іншою назвою. Будь ласка, майте на увазі під час прийняття.

constant() працює скрізь var() – наприклад, всередині paddingвластивостей:

.post {
    padding: 12px;
    padding-left: constant(safe-area-inset-left);
    padding-right: constant(safe-area-inset-right);
}

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

Приведення все це разом, з min() і max()

Цей розділ охоплює функції, які наразі не входять в iOS 11.

Якщо ви приймаєте константи вставки безпечного регіону у вашому дизайні веб-сайту, ви можете помітити, що дещо важко вказувати, що ви хочете мінімальне оздоблення на додаток до безпечної області вставки. На сторінці вище, де ми замінили нашу 12px лівою підкладкою з constant(safe-area-inset-left), коли ми повертаємо назад до портрета, ліва безпечна область вставки становить 0px, а текст сидить безпосередньо поруч із краєм екрана.

Щоб вирішити це, ми хочемо вказати, що наша прошивка повинна бути подушкою за замовчуванням або безпечною область вставки, залежно від того, що більше. Це може бути досягнуто з абсолютно новими функціями CSS min() і max() які будуть доступні в майбутніх версіях Safari Technology Preview. Обидві функції беруть довільну кількість аргументів і повертають мінімум або максимум. Вони можуть бути використані всередині calc(), або вкладені всередині один одного, і обидві функції дозволяють, calc() як-от математики всередині них.

Для цього ми хочемо використовувати max():

@supports(padding: max(0px)) {
    .post {
        padding-left: max(12px, constant(safe-area-inset-left));
        padding-right: max(12px, constant(safe-area-inset-right));
    }
}

Важливо використовувати @supports з функцією виявлення хв і макс, так як вони не підтримуються у всьому світі, і завдяки CSS в обробці недійсних змінних, щоб НЕ вказати змінну всередині вашого запиту @supports.

На нашому прикладі сторінка, в портретній орієнтації, constant(safe-area-inset-left) вирішує до 0 пікселів, тому max() функція вирішує до 12 пікселів. У пейзажі, коли constant(safe-area-inset-left) більше завдяки корпусу сенсора, max() функція буде вирішена до такого розміру замість того, щоб завжди помітний важливий вміст.

Досвідчені веб-розробники могли б раніше зіткнутися з механізмом блокування “CSS”, який зазвичай використовується для скріплення властивостей CSS до певного діапазону значень. Використання min() та max() взаємодія робить це набагато простіше, і буде дуже корисним у впровадженні ефективних адаптивних дизайнерів у майбутньому.

Переклад статті “Designing Websites for iPhone X“

WordPress 4.8.2 Оновлення безпеки та технічного обслуговування

WordPress 4.8.2 тепер доступний. Це випуск безпеки для всіх попередніх версій, і ми настійно рекомендуємо негайно оновлювати свої сайти. На версію WordPress версії 4.8.1 і раніше виникають такі проблеми безпеки:

1. $wpdb->prepare() може створювати непередбачені та небезпечні запити, що приводять до потенційної ін’єкції SQL (SQLi). Ядро WordPress не є безпосередньо вразливим до цієї проблеми, але ми додали зміцнення, щоб запобігти випадковому виникненню вразливостей плагінами та темами. Про це повідомляє Slavco
2. У відкритій oEmbed була виявлена ​​вразливість міжсторінкових сценаріїв (XSS). Повідомлено xknown від команди безпеки WordPress.
3. У візуальному редакторі була виявлена ​​уразливість між сценаріями через сайт (XSS). За повідомленням Rodolfo Assis (@brutelogic) Sucuri Security.
4. В коді розпакування файлу була виявлена ​​уява просування по шляху. Про це повідомляє Alex Chapman (noxrnet).
5. У редакторі плагінів була виявлена ​​уразливість між сценаріями через сайт (XSS). За повідомленням 陈瑞琦 (Чен Руйкі).
6. Відкрите перенаправлення було виявлено на екрані редагування користувача та терміна. За повідомленням Yasin Soliman (ysx).
7. У модифікаторі була виявлена ​​уява просування по шляху. Про це повідомляє Weston Ruter з команди WordPress Security.
8. В іменах шаблонів була виявлена ​​уразливість між сценаріями на різних сайтах (XSS). За повідомленнями Luka (sikic).
9. В модальному посиланні була виявлена ​​вразливість міжсторінкових сценаріїв (XSS). Про це повідомляє Anas Roubi (qasuar).

Дякую журналістам цих питань для здійснення відповідального розкриття інформації.

На додаток до вищезазначених питань безпеки, WordPress 4.8.2 містить 6 виправлень щодо обслуговування до версії 4.8. Щоб отримати додаткові відомості, див. Примітки до випуску або перегляньте список змін.

Завантажте WordPress 4.8.2 або перейдіть до Інформаційної панелі → Оновлення та просто натисніть кнопку «Оновити зараз».

Сайти, які підтримують автоматичні фонові оновлення, вже починають оновлюватися до WordPress 4.8.2.

Спасибі всім, хто внесли свій внесок у 4.8.2.

Переклад статті “WordPress 4.8.2 Security and Maintenance Release“

Чому ми перейшли з Angular 2 на Vue.js

У Rever (www.reverscore.com) ми просто випустили нову версію нашого веб-клієнта, використовуючи Vue.js. 641 commits і 16 тижнів інтенсивного розвитку після двох ресурсів, тут ми дуже пишаємося рішенням, яке ми займаємо деякий час тому.

8 місяців тому наш веб-клієнт використовував Angular 2. Точніше, він використовував Angular 2 beta 9. Це був продукт, написаний аутсорсинговою компанією, і ми ніколи не були повністю задоволені ним на багатьох рівнях: від UX / UI до архітектури, і до певного рівня, з самим Angular 2.

Перш ніж продовжувати, я визнаю, що Angular 2 beta 9 – це інший продукт, ніж Angular 2.0, але це була одна з проблем. З бета9 до 2.0.0 існує 8 бета-версій, 8 RC і сама версія версії 2.0.0, загалом 17 версій для оновлення. Ми спробували оновити версію з бета-версії 9 до 2.0.0, але забагато речей, які зроблять оновлення нетривіальним. Також приблизно в той самий час ми допитували Angular 2 як нашу основу вибору, команда Angular вирішила розпочати роботу над Angular 4. Хоча вони обіцяли, що це не буде надто різким, це означало, що до моменту завершення модернізації до Angular 2.0.0 нам знадобилося ще одне оновлення. Це велика трата часу коли обмежені ресурси.

Головне, що нам не сподобалося, і нам все ще не подобається Angular 2 – Typescript. Я знаю, що Angular 2 можна використовувати з Javascript, але знову ж таки рішення про використання Typescript вже було прийнято, і з того, що я розумію, використання чистого Javascript з Angular 2 не є ідеальним способом використання Angular 2. У будь-якому випадку звільнення з Typescript означав повне переписання проекту.

Я не відчував, що Typescript додала істотну цінність і, що ще гірше, ми помітили, що наша швидкість кодування була зменшена. З Typescript речі, які дійсно було легко виконувати в Javascript, як визначення простого об’єкта, були складнішими для Typescript.

Я до сих пір пам’ятаю, як легко працювати з Angular 1, це, безумовно, були власні проблеми, але було приємно працювати з ним у порівнянні з іншими frameworks, щось що Angular 2 втратила десь на своєму шляху. Мій висновок про Angular 2 був простим, єдине, що є унікальним у Angular 1 і 2 загальної назви, вони абсолютно різні frameworks.

Тому вважають, що у нас було 17 версій для оновлення на неперевіреній системі, великий тиск з боку бізнесу, щоб написати нові функції, багато помилок і погано написаний код, оригінальні розробники більше не були в команді, тільки одиному розробнику (мені) в той час з багатьма іншими обов’язками, Typescript, проблеми з пошуком потрібної документації, оскільки я використовував бета-версію, а Angular 2 перейшов до версії 4. Список негативів почав накопичуватися дуже швидко.

Ми прийняли рішення, якщо ми хочемо витратити стільки часу на оновлення, нам потрібно було побачити. І ми це зробили.

React

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

Vue.js

Vue.js був новим гравцем, я ніколи не чув про це раніше, вони тількі випустили версію 2, коли ми почали шукати різні варіанти. Спочатку це привернуло нашу увагу, і виглядало ризиковано.

Процес прийняття рішень

Спочатку ми почали визначати, які саме пункти нашого рішення мають бути. Ми знали, що рамки наших мрій потребують наступного:

1. Вона повинна бути стабільною
2. За підтримки сильної громади або деяких великих гравців
3. Хороша документація або багато питань про StackOverflow
4. Легко навчатися
5. Інтеграція з Bootstrap
6. Маленький розмір
7. В ідеалі це дозволить нам повторно використовувати код
8. Тест швидкості кодування повинен бути підвищений
9. Реактивність
10. Компонент на основі

Після того, як вирішили свої рішення, мені довелося б забруднити мої руки, тому я кодив на React і Vue.js пару днів, щоб переглянути кожну точку прийняття рішення, про яку Google не буде відповідати. Оскільки я нічого про них нічого не знав, наприкінці двох днів я б переоцінив, як далеко я перейшов на переписування деяких частин проекту, який ми збираємося мігрувати.

Частини, які я вирішив переписати, були:

1. Деякі основні виклики API
2. Два макети для двох різних сторінок.
3. Реактивність для користувачів, пов’язаних із матеріалами
4. Вхідні форми та деякі формати вмісту
5. Один з варіантів завантаження

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

React булв набагато складніше, ніж я думав, вибираючи між Redux і MobX є більш проблематичним, ніж мати один варіант, який добре інтегрований з framework, як Vue.js і Vuex do.

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

JSX також була проблемою, оскільки ми не змогли повторно використовувати HTML-код, і Vue.js дозволив нам це зробити певною мірою. З файлами Vue насправді дуже добре працювати, оскільки мені не подобаються вбудовані шаблони. Реагуйте суміші як JSX/HTML з кодом JS, яким я просто не люблю, оскільки я сильно вірю в поділ проблем, і це виглядає потворним IMHO.

Швидкість кодування

Швидкість кодування – виграв Vue.js, не маючи досвіду, з JSX мав величезну допомогу. Ця швидкість була пізніше підтверджена, коли ще один розробник приєднався до проекту і долучився до проекту через декілька годин після тренувального сеансу близько 1 години.

Це було надзвичайно важливим для нас, і ви можете побачити це відразу, відкривши файл VUE. Він містить розділ шаблону з HTML та теги, які виглядають схожими на Angular 1, тому, якщо ви зробили деякий Angular 1, це буде справді знайоме. У файл ви також має стилі і чисті JavaScript розділи, де ви на насправді використовувати яваскрипт і вам потрібно тільки дізнатися кілька речей, про Vue.js та повністю зрозуміти їх. Розуміння Vue.js властивості, такі як methods, computed, properties, data та created перенесе вам близько 90% того, що вам потрібно зрозуміти, щоб почати кодування, дуже легко.

Документація

Щоб мати належну швидкість, нам потрібна хороша документація, і документація Vue.js чудова. Довідники, приклади, питання та API дуже добре оформлені та охоплюють усі сумніви, які ми виявили під час розробки. Ми боялися знайти китайську документацію для багатьох питань, які ми мали б, але це не так, все було доступно англійською мовою.

Запитую навколо

Vue.js виглядав дуже добре після більш ніж тижня розгляду, але, на мій подив, запитання навколо було марним, тому що ніхто раніше не користувався Vue.js, єдиний коментар, який я отримав, був у порядку “виглядає чудово, але я його не використовував”. Reack зайняв найбільше згадування, а Angular 2 вийшов на віддалене друге місце.

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

Мобільний

У той час, коли ми думали про Vue.js і React, ми також планували переробити наш мобільний додаток і React Native виглядав як дуже хороший вибір. Це був великий плюс для React, оскільки Vue.js не мав нічого віддалено стійкого, який нагадує те, що намагається зробити React Native, тому можливість повторного використання коду між веб-програмами та клієнтами була величезним плюсом, але я вирішив, що я не збирається розглядати можливості, які могли б або не відбулися. Зрештою, з мого досвіду, з Node.js я повторно використовую дійсно незначну кількість коду між браузером та сервером.

Ліцензування

У той час, коли я пишу це, є велика кількість обговорень, оскільки Facebook змінив ліцензію React на BSD + Patents. Відповідно до Facebook, ця ліцензія призначена для захисту від патентних тролів. Це було не першочерговим у процесі прийняття рішень, але я радий, що ми не використовували на “React”, оскільки будь-який шум, пов’язаний з Ліцензіями, не є шумом, який ви хочете почути.

Врешті-решт, Facebook, що стоїть позаду React, може стати відповідальністю за проект замість сили, тому, як правило, краще мати незалежні фонди або організації, які відповідають за успішний проект із відкритим вихідним кодом. Facebook має робити правильно, наприклад, IBM, як приклад, коли IBM купив Strongloop, вони пожертвували Express.js на фонд Node.js, де належить таке важливе програмне забезпечення. Тиск з боку суспільства та бажання IBM забезпечити безперервність програмного забезпечення зробили це. Ще один хороший приклад Twitter – це випуск Bootstrap під ліцензією MIT, і ніхто не говорить про ліцензійні проблеми з Bootstrap.

Заключні слова

В цілому, Vue.js був переможцем у нашій оцінці, він мав багато відповідей на запитання стосовно переповнення стеків, найяскравішу офіційну документацію з трьох варіантів, найменшу кодову базу, добре інтегрується з Bootstrap і дізнався, що вона підтримується сильними проектами, такими як Laravel та велика компанія, така як Алібаба, була великим плюсом. Не маючи такої великої громади, як React, це був не реальний фактор, оскільки він був досить великим.

Вибір з Vue.js був правильним вибором, мені довелося переконати мого технічного директора, але я вдячний, що він завжди задавав правильні і важкі питання і змушував мене бути 100% впевненим у своєму рішенні, я збирався пошкодувати це якщо я зробив помилку Я думаю, що була невелика частина його, що не було впевнено, поки він не написав цілий компонент і виявив це дуже просто.

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

Я не кажу, що React – це поганий вибір, я здивований тим, наскільки велика спільнота, і є хороша причина, але jQuery більше, і це не робить його гарною структурою / бібліотекою для проекту, який ми хотіли зробити.

Vue.js набирає обертів, і ми бачили, що під час розробки, що лише запевнило нас, що ми зробили правильний вибір. Ми цінуємо простоту, і Vue.js досягає того, що ця простота відображається на кривій навчання, документації та особливості швидкості кодування.

Переклад статті “Why we moved from Angular 2 to Vue.js (and why we didn’t choose React)“

Що таке Web Sockets?

Web Sockets – це найсучасніша технологія, що дозволяє здійснювати інтерактивне спілкування в режимі реального часу між клієнтським браузером та сервером. Він використовує зовсім інший протокол, який дозволяє двонаправлену передачу даних, що робить його унікальним щодо HTTP. (більше…)

Стан CSS в Angular

Застосування для створення стилів є важливою частиною для користувачів. Ми маємо каскадні таблиці стилів (CSS), як потужний стандарт для розробників, щоб визначити зовнішній вигляд програми окремо від його конструкції.

За замовчуванням в Angular, коли ви прикріплюєте CSS безпосередньо до компонента, ми обмежуємо область CSS виключно для цього компонента. Це обкладинка виділяє його з іншої частини вашої програми. Ця додаткова можливість означає, що існує два способи використання CSS з Angular.

Глобальний CSS – спосіб, яким ви користуєтеся

Поки CSS існує, стилі, завантажені на сторінку, застосовуються глобально до кожного відповідного елемента на цій сторінці. Більшість розробників кожен день працюють із таким світовим стилем, і громада розробила безліч різних підходів для управління та організації цього, починаючи від простих префіксів до більш активних систем, таких як BEM та OOCS.

Компоненти Angular можна створити за допомогою глобальної CSS так само, як і будь-який інший елемент у вашій програмі. Просто перетягніть елемент <link> на свою сторінку (зазвичай в index.html), і вам добре йти! Тим не менш, Angular додатково дає розробникам більше можливостей для обчислення ваших стилів.

Компонентний CSS

Компонентна модель Angular дає змогу розробникам максимально наблизитись до ізоляції. Це стосується і стилів, де несподівані побічні ефекти від CSS можуть бути небажаними.

Ми всі були в ситуації, коли, здавалося б, незручні зміни, такі як переміщення компонентів в інше місце, викликали несподіваний каскад змін. Це може статися, коли стилі, що недостатньо обґрунтовані, повністю скидають макет сторінки. Щоб уникнути подібних вражень, Angular буде застосовувати стилі компонента таким чином, що вони застосовуватимуться лише у шаблоні цього компонента.

Три режими інкапсуляції компонентів

Розробники, які використовують компонентний CSS в Angular, за умовчанням використовують емульований режим для цієї інкапсуляції. У емулятивному режимі ми генеруємо та прикріплюємо випадкові атрибути до кожного компонента, який створюється, а потім створюємо стилі, які використовують ці сформовані атрибути як селектори.

Ми також підтримуємо Native режим, який використовуватиме Shadow DOM для створення додаткових контекстів і запобігання витікання стилів з різних компонентів. Це буде працювати в будь-яких браузерах з підтримкою Shadow DOM v1. Рідний режим створює корінь тіні під кожним компонентом, що повністю ізолює компонент, навіть від стилів, визначених у глобальному масштабі (глобальні стилі DO проникають компоненти з імульованим представленням інкапсуляції).

Третя і остання інкапсуляція, яку ви можете вибрати, – ” Ні” , тобто всі ваші CSS закінчуються в глобальному масштабі. Ви можете використовувати це, якщо ви хочете повністю відмовитися від інкапсуляції стилю Angular.

Дізнайтеся більше про компонентний CSS

Глибокий CSS

Але що, якщо я хотів об’єднати ці два світи? Я хочу написати компонентний CSS, який впливає на сам компонент, а також на будь-які діти, які я вклав всередину.

Angular та браузери історично пропонують те, що зазвичай називають глибоким селектором. Це також відомо декількома іншими іменами, у тому числі >>>, /deep/, або більш офіційним комбінатором послідовності Shadow-Pieriring.

Глибокий Селектор виник як зусилля команди Blink. Це дозволило розробникам додавати стиль через тіньові коріння. Врешті-решт, він не підтримував стандартизацію, продуктивність і очікування розробників.
Перед виходом Angular версії 4.3 зміни в таких інструментах, як SASS та інші оголошення, означають, що наша існуюча інтерпретація /deep/ створює конфлікти. Щоб дати розробникам тимчасову відмову від цих зовнішніх змін, ми створили ::ng-deep, що досягає такої ж функціональності.

Оскільки ми хочемо, щоб наша емуляція та інсталяція нативного стилю як функціональність була еквівалентною (з надією на майбутню стандартизацію браузера), ми не рекомендуємо нове прийняття /deep/ or ::ng-deep, коли ви можете уникнути цього.

Існує хороше висвітлення ::ng-deep та історія цієї функції в статті Dor Moshe .

Але я хочу цю функціональність!

Ми розуміємо, що існують законні випадки використання компонентів CSS, де ваші стилі проникають у дочірні компоненти. Ось три способи, до яких можна досягти цього:

• Використання спеціальних властивостей (AKA CSS Variables) – хоча ще немає повної підтримки браузера для користувацьких властивостей, впровадження браузера цих можливостей дасть розробникам найкраще поєднання ізоляції та гнучкості. Властиві властивості, по суті, дозволяють авторам компонентів визначати поверхню API для стилів їхніх компонентів; Вони дозволяють розробникам вирішувати, що слід стилювати ззовні, і що потрібно зберігати послідовно.
• Використовуйте аркуші стилів глобального масштабу та емульовану інкапсуляцію.  Використовуючи традиційну CSS, ви можете посилатися на компоненти за назвою як частину CSS-селекторів, які призведуть до застосування стилів, як вони завжди існують, включаючи проколювання до дочірніх компонентів, припускаючи, що ви використовуєте нашу емуляцію (За замовчуванням) переглянути інкапсуляцію на компоненти.
• Використовуйте ::ng-deep  – якщо вам це потрібно сьогодні, використовуйте ::ng-deep. Це не повинно суперечити будь-яким інструментам стороннього розробника або розробці нових веб-переглядачів. Ми зобов’язуємося без збереження ::ng-deep навколо до підходу стандартів на основі досягла загальногалузевий підтримки.

Колективний відгук дуже важливий для нас. Ми вирішили підтримувати підтримку ::ng-deep, доки користувацькі властивості не зможуть досягти ширшого прийняття, впровадження та перевірки від розробників. Ми це частково завдяки відгукам та вкладам нашої громади. Дякую за вашу постійну підтримку та відгуки, оскільки ми продовжуємо робити Angular краще та краще.

Переклад статті “The State of CSS in Angular“

Приховування деталей реалізаціі з Flow за допомогою псевдоніму непрозорого типу (Opaque Type Aliases)

Ви коли-небудь хотіли б, щоб ви могли приховати свої дані про виконання у своїх користувачів?

Ну, тепер всі ваші мрії нарешті збулися! У Flow 0.51.0 додано підтримку для псевдонімів непрозорих типів (Opaque Type), з підтримкою babel, що надходить наступного тижня або близько того. Псевдоніми непрозорого типу є псевдонімами типу, які приховують їх основний тип. Ви можете бачити лише основний тип непрозорого типу (Opaque Type) у файлі, який оголошує непрозорий тип. Вони вже описані тут , тому ми проведемо решту цього повідомлення в блозі, показуючи, наскільки потужні псевдоніми мають непрозорі типи (Opaque Type).

Підтримка інваріантів з непрозорими типами (Opaque Type)

Неактивні типи псевдонімів дійсно корисні для підтримки інваріантів у вашому коді. Кожного разу, коли ви хочете висловити “речі типу T, де X є істинним”, ви можете розглянути питання про використання непрозорого типу псевдоніму (Opaque Type).

Як простий приклад, розглянемо тип для невід’ємних чисел:

NonNeg.js:
// @flow
opaque type NonNeg = number;

Тепер ми можемо виконувати деякі функції для взаємодії з NonNeg номерами:

NonNeg.js:
// @flow
opaque type NonNeg = number;
export function add(x: NonNeg, y: NonNeg): NonNeg {
  return x + y;
}
// Returns 0 at minimum
export function subtract(x: NonNeg, y: NonNeg): NonNeg {
  return Math.max(0, x - y);
}
export function zero(): NonNeg {
  return 0;
}
export function increment(x: NonNeg): NonNeg {
  return x + 1;
}

Створення непрозорого типу псевдоніма (Opaque Type) – це подібно до укладення договору з вашим користувачем: якщо вони погоджуються використовувати вашу бібліотеку лише для взаємодії з вашим типом, ви будете зберігати будь-який інваріантний ваш тип гарантії.

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

imports.js:
// @flow
import {add, subtract, zero} from './NonNeg';
const w = zero();
const x = increment(w);
const y = add(w, x);
const z = subtract(y, w);

Тепер, мабуть, один з наших користувачів намагається порушити наш інваріант:

bad-usage.js:
// @flow
import {zero} from './NonNeg';
let a = zero();
let b: NonNeg = a - 1;

Оскільки ми використовували псевдонім непрозорого типу (Opaque Type), який не виявляє його тип за межами визначального файлу, він отримає помилку:

Error: a = a - 1;
           ^ Error: a is NonNeg, which is incompatible with number.

Чудово! Ми змогли використати Flow, щоб захистити наш NonNeg інваріант! Але це може бути надто обмеженим. Врешті-решт, неотрицательный номер все ще є числом, тому ми повинні мати можливість використовувати його як такий.

Обмеження підтипу

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

NonNeg.js:
// @flow
opaque type NonNeg: number = number;
/* ... */

Додавання : number до нашого непрозорого типу псевдоніму повідомляє Flow, що кожен NonNeg є number. Проте це не означає, що кожен number має значення NonNeg.

Тепер давайте ще раз поглянемо на код клієнта. Є ще помилка!

let b: NonNeg = a - 1;
                ^ Error: number. This type is incompatible with
let b: NonNeg = a - 1;
       ^ opaque type `NonNeg`.

Зверніть увагу, що тепер потоки інтерпретуються a — 1 як число, але не дозволятимуть його присвоювати змінній, яка є NonNeg. Якщо ми хочемо використовувати значення a як число, нам доведеться використовувати його в тому місці, де очікується число.

let b: number = a - 1; // Ok!

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

Ще кілька випадків використання

• Ви використовуєте рядки, щоб представляти унікальні ідентифікатори у вашій програмі? Не всі рядки є ідентифікаторами – ви можете використовувати псевдонім непрозорого типу, щоб переконатися, що жодні випадкові рядки не передаються навколо прикидаються ідентифікаторами!
• У вас є два псевдоніми типу з однаковими основними типами, але зовсім іншими способами? Якщо ви зробите їх непрозорими, ви не зможете замінити їх на інший!
• Чи ви уважно стежите за складними інваріантами у вашій структурі даних і хочете захистити користувачів від їх руйнування? Огоронить його за допомогою псевдоніму непрозорого типу!

Висновок

Непрозорі типи в Flow – це контракт із користувачами вашого типу. Контракт може бути вічно обов’язковим, якщо у вас немає іншого вибору, крім використання ваших функцій. Крім того, ви можете надати користувачеві витяг підтипу, який дозволяє користувачеві розірвати контракт, коли це буде потрібно.

Переклад статті “Hiding Implementation Details With Flow’s New Opaque Type Aliases Feature“

Як задеплоіть веб-додаток на зв`язці React і Redux за 10 хвилин

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

Ви отримаєте аналогічне додаток після виконання цих дій:

• локальна установка ReactJS за допомогою шаблону;
• настройка «кошика» AWS (Amazon Web Services) S3;
• створення облікових даних користувача AWS для завантаження файлів на S3;
• розгортання шаблону на AWS;
• перевірка працездатності.

Необхідні інструменти:

• Node.js версії 6.0 або вище;
• Yarn;
• Аккаунт AWS (безкоштовного буде достатньо).

1. Установка ReactJS

Клонуємо шаблон (запустіть команду в терміналі), замінивши «NameOfApp» на ім’я свого застосування:

$ git clone -o onederful-quickstart -b master --single-branch \
       https://github.com/alxyee/onederful-quickstart.git NameOfApp
$ cd NameOfApp

Встановлюємо всі бібліотеки:

$ yarn install

Запускаємо React по локальній адресі http://localhost:3000/ (запуск може зайняти кілька секунд):

$ yarn start

2. Налаштування кошика AWS S3

Входимо в свій аккаунт на AWS і вибираємо S3:

Натискаємо «Create bucket» і вводимо ім’я (наприклад: onederful-quickstart). Натискаємо «Далі» на всіх інших кроках і створюємо кошик (bucket):

Тепер відкриваємо тільки що створену кошик:

Після появи спливаючого вікна натискаємо на «Properties»:

Натискаємо на «Static website hosting» і вводимо «index.html» в кожному з полів «Index document» і «Error document». Тепер у нас є загальнодоступний URL:

Переходимо на вкладку «Permissions», замість [YOUR BUCKET NAME] вписуємо свою назву проекту:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPublicRead",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::[YOUR BUCKET NAME]/*"
        }
    ]
}

3. Створюємо облікові дані користувача AWS для завантаження файлів на S3

В консолі управління AWS натискаємо на «IAM» (Identity Access Manager):

Переходимо на вкладку «Users», що знаходиться на бічній панелі, і додаємо користувача з ім’ям «s3-admin»:

Прикріплюємо «AmazonS3FullAccess policy»:

Після створення користувача зберігаємо ідентифікатор доступу і секретний ключ (наприклад, в блокноті) – вони будуть використовуватися на останньому етапі цього керівництва:

4. Публікуємо шаблон на AWS

Замініть наступні дані у файлі tools/s3-upload.js:

• YOUR_BUCKET_NAME – на назву кошика (з другого кроку);
• YOUR_AWS_ACCESS_KEY – на свій ідентифікатор доступу (з третього кроку);
• YOUR_AWS_SECRET_KEY – на свій секретний ключ (з третього кроку).

Публікуємо додаток:

$ yarn publish:webapp

5. Перевіряємо працездатність і починаємо створювати додаток

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

Налаштування AWS повинна виконуватися тільки один раз, тому після внесення будь-яких змін в ваш додаток можна просто запустити команду deploy, і протягом декількох секунд зміни вступлять в силу.

Переклад статті «How to deploy a live ReactJS / Redux website in under 10 minutes»

Ласкаво просимо до Angular 4

З моменту виходу, Angular 4 є єдиною версією Angular, про яку всі говорять. Хоча, як стверджується, він побудований на старшому Angular 2, це повне оновлення. Він не дотримується тих самих правил, а створює власні нові.

Новішу версію називають легшою, швидшою і кращою версією Angular, що робить її однією з найбільш швидко адаптованих версій Angular. Ось деякі відмінності між Angular 2 і Angular 4. (більше…)

QML проти HTML5

Мобільні пристрої встановили стандарт з точки зору чуйності та зручності для користувачів HMI у різних галузях. Виробники автомобілів, медичного обладнання, систем промислової автоматизації та побутової електроніки тепер хочуть відтворити цей чудовий досвід для своїх вбудованих пристроїв. Щоб з’ясувати, яку технологічну стратегію ми повинні вибирати, ми створили тест, на якому для одного розробника було виділено 160 годин, щоб створити демонстраційний додаток вбудованої системи з використанням Qt & QML та однакову кількість годин, щоб створити дуже еквівалентну програму з використанням HTML5. (більше…)

8 npm трюків, які ви можете використовувати для враження своїх колег

У цій статті ви знайдете кілька зручних команд для роботи з npm – менеджером пакетів, що входять до складу Node.js. З усього безлічі існуючих ми вибрали ті, які можуть бути найбільш корисні при щоденному використанні.

Базові скорочення

Спочатку згадаємо найвідоміші скорочення для установки:

• встановити пакет: npm install pkg, скорочення: npm i pkg;
• встановити пакет глобально: npm i –global pkg, Скорочення: npm i -g pkg;
• встановити пакет і зберегти як залежність: npm i –save pkg, Скорочення: npm i -S pkg;
• встановити пакет тільки для використання в розробці (devDependency): npm i –save-dev pkg, Скорочення: npm i -D pkg.

Інші скорочення можна подивитися на офіційному сайті npm.

1. Ініціалізація нового пакета

Перша дія при створенні нового пакета – npm init:

Якщо питання здаються вам зайвими і ви хочете їх проскочити, використовуйте npm init -y або npm init -f:

2. Тестування

Часто використовувану команду npm test можна замінити на npm t, вона робить те ж саме:

3. Доступні скрипти

При роботі над новим проектом ви, швидше за все, цікавитеся, що взагалі можна запустити в його рамках. Можна відкрити файл package.json і перевірити секцію scripts:

Але список доступних скриптів можна отримати і через npm run:

Ще варіант – встановити інтерактивне меню ntl (npm i -g ntl) і запустити в папці проекту:

4. Встановлені пакети

Для перевірки залежностей теж можна було б зайти в package.json, але є варіант трохи краще – npm ls –depth 0:

Для перевірки пакетів, встановлених глобально, підходить та ж команда з відповідним прапором – npm ls -g –depth 0:

5. Запуск локально встановлених модулів

Ми встановили пакет, в ньому є виконуваний модуль, але він працює тільки при запуску через npm-скрипти. Чому це так, і як цього уникнути?

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

При запуску виконуваних модулів через npm-скрипти менеджер пакетів додає додаткову папку до PATH, <директорія проекту>/node_modules/.bin. Її можна знайти, запустивши npm run env | grep "$PATH". За допомогою npm run env можна побачити всі доступні змінні оточення.

У node_modules/.bin локально встановлені пакети розміщують свої виконавчі модулі. Запускаємо ./node_modules/.bin/mochaв директорії проекту:

Просто пишіть ./node_modules/.bin/<команда>, коли хочете запустити локально встановлений виконуваний модуль.

6. Знайти пакет в Інтернеті

У файлі package.json ви могли помітити запис repository. Для того, щоб відкрити відповідний репозиторій в браузері, запустіть команду npm repo. Команда npm home виконує ту ж функцію для запису homepage. Якщо ви хочете відкрити пакет на офіційному сайті , використовуйте команду npm docs.

7. Запуск скриптів до і після інших скриптів

Ви швидше за все знайомі зі скриптом pretest, він дозволяє визначити код, який слід запустити перед скриптом test. Виявляється, pre і post скрипти можна створювати для будь-яких інших скриптів, в тому числі кастомних:

8. Оновити версію пакета

Припустимо, ви використовуєте semver для управління версіями і хочете оновити версію перед черговим релізом. Можна відкрити package.json і зробити це вручну, але навіщо?

Ще простіше – запустити команду npm version з major, minor або patch:

Ще кілька порад можна знайти в спеціальному сховищі на GitHub , де крім цього зібрані різні корисні інструменти і посилання на ресурси, пов’язані з npm.

Переклад статті «8 npm Tricks You Can Use to Impress Your Colleagues»