А можно тоже самое, только с ссылкам на почитать?
И это же сколько лет это потребуется узучать?
(сколько лет потребуется чтобы написать учебный материал)
Эх, все зло и тормоза от Альфы. Каких только технологий не придумали чтобы сделать жизнь чуть чуть лучше, но до победы далеко.
А самое главное, что любая полупрозрачность (текст) требует активного режима смешивания который просто сразу в два раза все просаживает.
В свое время пытался рендерить различные сущьности в отдельные текстуры, чтобы потом в шейдере сразу все склеить. TMU сейчас ой как много.
От сюда и вопрос — а как ФФ склеивает слои? glBlend не предлагать.
«Хороший» способ оптимизации — ограничивать область распространения изменений. Не надо вешать на каждый чих shouldUpdate, достаточно в узловых местах добавить connect, которые будет ташить данные из стора, а не родителя, создавать как бы «автономную» область.
Ну и не стоит забывать что connect создает PureComponent, который только на изменение стора и реагирует.
Но вообще, по моему опыту, большая часть зла исходит от самого реакта и его экосистемы, чем он кривых рук конечного програмиста.
Испытательный срок — крайне плохая идея, если в начале надо уволиться из текущей компании, продать дом, и переехать на другой континент.
Я, например, стараюсь заворачивать кандидата при малейшем намеке на то, что он может не пройти.
У вас метод индукции сбоит. В данный момент безаппеляционные утверждения исходят только с вашей стороны.
Вроде как приверженность только одного взгляда — и есть проявление радикального.
У меня каждый день есть возможности видеть плюсы и минусы разных подходов на разных языках… и в большинстве случаев использование «классического» DI — это или Java, или объектно ориентированный говнокод 5-то летней давности.
Но «нормальный» DI(уровня SpringBoot/ng-di) на самом деле редкий зверь в мире JavaScript. Есть взять пяток самых популярный библиотек, убрать то что для ng, и посмотреть на статистику скачек — будет не очень. Плюс многие путают DI с более широким IoT.
DI хорош, когда в одну и туже розетку можно засунуть разные вилки. Если пара вилка/розетка всегда одна, и DI — исключительно для тестов — может его и не надо?
И, самое главное, многие вещи просто принято использовать «как есть». Именно поэтому 90% примеров моканья чего либо, мокают: fs, сеть, session storage, селекторы в редаксе и другой environment.
У меня и самого есть проект на inject-loader, и я им в принципе доволен. Но иногда по пути попадаются грабли, на которые редко, да наступаю.
Давайте придумаем немного синтетический пример:
import function1 from 'module1';
export default () => function1()+1;
После чего мы просто мокаем module1 и expect(function1).to.be.called();
Проходит время, и Вася добавляет еще одну строчку:
import function1 from 'module1';
import function2 from 'module2';
export default () => function1()+function2()+1;
Но он не меняет тесты, а тесты как работали, так и работают.
Бывает и обратная ситуация — вы убираете строчку, а тесты как работали, так и работают.
Беда в том, что тесты должны не только «тестировать» поведение функции, те проверять результат — они должны служить вторым контуром проверки, обеспечивать еще один «момент подумать».
И, по хорошему, должны падать при _любом_ изменении логики програмы. Просто потому что они должны его детектить и подносить вам на блюдечке.
Да — совсем не круто править 10 тестов после того как изменил одну запятую. Но еще более не круто – не догадываться, что вы изменили чуть больше логики, чем думаете, этой одной запятой.
В свое время я пытался пропихнуть API для этого в proxyquire, но не срослось.
В rewiremock для мока можно определить то как он может быть вызван — toBeUsed, directChildOnly, calledFromMock, плюс режим isolation который будет ругаться на каждый неожиданный import.
Раз уж units tests are production code — относитесь к ним соотвествующе. Хотя конечно можно добавить тесты для тестов, но нельзя добавить тесты для моков, те заставить моки соотвествовать интерфейсам того, кого они собой замещают – тут нужен DI. Но он тоже не сахар.
Чувствуется опыт, друг ошибок трудных.
С aria-hidden/busy, насколько я понимаю, история уровня zoom:1 – в общем мы методом тыка проверили как лучше, и лучше вот так. За стандарт немного обидно, но в вебе так везде и всегда.
Ну насчет aria-hidden – лично меня спецификация не очень убедила. Точнее он все еще более правильный чем aria-busy, тем более достаточно часто контент за пределами модала и не виден пользователю (или не читабелен).
Пока самое хорошее решение — или inert или blockingElements. Но ни того, ни другого в браузеры не завезли.
С фокусом проблем нет — банально проверено на читалках. Но вообще тест очень простой — после ловушки на очень большом растоянии располагалается еще один фокусируемый элемент. Если фокус перескочет на него — произойдет скрол страницы. Но если вызвать preventDefault — то скрола не будет.
Другая проблема что порядок таббания отличается от перехода по элементам стрелками(VioceOver), что (конечно же) может все сломать и с этим уже бороться бесполезно.
Вы немного не последовательны:
1. Во первых aria-busy придуман не для этого. Основной контент надо именно «прятать», для чего нужен aria-hidden. И это относится исключительно к пункту 3.
2. А вот пункты 2 и 3 различать не надо. Есть два события — focusIn, когда фокус куда-то пришел, и focusOut, когда он откуда-то ушел.
Большинство библиотек агрятся на попытку фокуса покинуть ловушку, те focusOut, где новый элемент будет записан в relatedTarget. При этом ловушку в любом случае можно покинуть уйдя в адресную строку браузера, и на этом все сломается. Выбрался — значит свободен.
Плюс focusOut — его можно(и нужно) вешать на свою ноду.
К сожалению, так как это не очень работает, требуется вешать хэндлер на focusIn глобально на документе. Теперь, когда что-то за пределами ловушки получает фокус — можно будет этот фокус взять и положить обратно.
Ну а в итоге требуется вешать события и туда и туда.
И самое главное — НИЧЕГО кроме операций с фокусом делать не надо. Никакие keyboard/mouse/touch events.
Тоже самое относиться к предложеным фокусным ловушкам по краям основной. Главный поинт в том, что эти ловушки должны быть за пределами, а не внутри. И исключительно чтобы между началом/конца документа и модалом был что-то таббательное.
И в таком случае их вообще можно не включать в состав библиотеки — focus-lock/dom-focus-lock не могут менять верстку.
Спасибо. Совсем забыл про эту «фичу», когда внутри focus-lock находяться первый элемент с tabIndex=1, который оказывается самым-самым первым на странице.
В общем случае с самого первого или самого последнего можно выйти во внешний мир и/или просто начать не правильно работать.
Пофиксил react версию focus-lock просто добавим элемент с tabIndex=1 за пределами ловушки, и обновил ссылки на примеры в статье — теперь работают секси.
PS: Я вообще не совсем уверен откуда я взял старую ссылку — она использует старую версию библиотек. В общем спасибо за комментарий.
>наличие публикаций, наличие ссылок на публикации, участие в оценке работы других, важный вклад в область профессиональной деятельности… была пара патентов, и мы решили опираться на это.
Честно говоря достаточно не типичный набор для современного программиста, ведь хабратопик за публикацию не считается, как и комменты к нему не относятся к рецензиям, но вопрос в другом:
Насколько все это формально, и может ли переходить колличество в качество.
Австралии, где я сейчас нахожусь, требуется только образование и опыт работы. На колличество патентов, звезд на гитхабе и профессиональный уровень вообще — глубоко фиолетово.
Есть HTML driven by CSS — это BEM, где у вас нет проблемы с CSS, но все остальное пляшет под его дудку
Есть CSS driven by CSS — это Tachyons/Turrent и другой atom/functional CSS. Где CSS-а практически нет, зато в html.
<button class="bg-purple f6 br3 ph3 pv2 white hover-bg-light-purple">
И есть CSS-in-JS/ShadowDOM который разными путями немного исправляет генетику CSS+HTML и к нему следует применять немного другие подходы, потому что НЕ нужно именовать что либо по BEM-методолигии так как нет _необходимости_.
>Тем кто хочет идти работать в Y, думаю, точно стоит вчитаться и попробовать
В Яндексе есть много мест где никакого БЕМа нет.
И это же сколько лет это потребуется узучать?
(сколько лет потребуется чтобы написать учебный материал)
А самое главное, что любая полупрозрачность (текст) требует активного режима смешивания который просто сразу в два раза все просаживает.
В свое время пытался рендерить различные сущьности в отдельные текстуры, чтобы потом в шейдере сразу все склеить. TMU сейчас ой как много.
От сюда и вопрос — а как ФФ склеивает слои? glBlend не предлагать.
Ну и не стоит забывать что connect создает PureComponent, который только на изменение стора и реагирует.
Но вообще, по моему опыту, большая часть зла исходит от самого реакта и его экосистемы, чем он кривых рук конечного програмиста.
Суд США приравнял сайты к публичным местам. В общем приехали.
Испытательный срок 6 месяцев, который в Австралии прям на законодательном уровне, никто не отменял.
Испытательный срок — крайне плохая идея, если в начале надо уволиться из текущей компании, продать дом, и переехать на другой континент.
Я, например, стараюсь заворачивать кандидата при малейшем намеке на то, что он может не пройти.
У вас метод индукции сбоит. В данный момент безаппеляционные утверждения исходят только с вашей стороны.
Вроде как приверженность только одного взгляда — и есть проявление радикального.
У меня каждый день есть возможности видеть плюсы и минусы разных подходов на разных языках… и в большинстве случаев использование «классического» DI — это или Java, или объектно ориентированный говнокод 5-то летней давности.
DI хорош, когда в одну и туже розетку можно засунуть разные вилки. Если пара вилка/розетка всегда одна, и DI — исключительно для тестов — может его и не надо?
И, самое главное, многие вещи просто принято использовать «как есть». Именно поэтому 90% примеров моканья чего либо, мокают: fs, сеть, session storage, селекторы в редаксе и другой environment.
Давайте придумаем немного синтетический пример:
После чего мы просто мокаем module1 и expect(function1).to.be.called();
Проходит время, и Вася добавляет еще одну строчку:
Но он не меняет тесты, а тесты как работали, так и работают.
Бывает и обратная ситуация — вы убираете строчку, а тесты как работали, так и работают.
Беда в том, что тесты должны не только «тестировать» поведение функции, те проверять результат — они должны служить вторым контуром проверки, обеспечивать еще один «момент подумать».
И, по хорошему, должны падать при _любом_ изменении логики програмы. Просто потому что они должны его детектить и подносить вам на блюдечке.
Да — совсем не круто править 10 тестов после того как изменил одну запятую. Но еще более не круто – не догадываться, что вы изменили чуть больше логики, чем думаете, этой одной запятой.
В свое время я пытался пропихнуть API для этого в proxyquire, но не срослось.
В rewiremock для мока можно определить то как он может быть вызван — toBeUsed, directChildOnly, calledFromMock, плюс режим isolation который будет ругаться на каждый неожиданный import.
Раз уж units tests are production code — относитесь к ним соотвествующе. Хотя конечно можно добавить тесты для тестов, но нельзя добавить тесты для моков, те заставить моки соотвествовать интерфейсам того, кого они собой замещают – тут нужен DI. Но он тоже не сахар.
С aria-hidden/busy, насколько я понимаю, история уровня zoom:1 – в общем мы методом тыка проверили как лучше, и лучше вот так. За стандарт немного обидно, но в вебе так везде и всегда.
Пока самое хорошее решение — или inert или blockingElements. Но ни того, ни другого в браузеры не завезли.
С фокусом проблем нет — банально проверено на читалках. Но вообще тест очень простой — после ловушки на очень большом растоянии располагалается еще один фокусируемый элемент. Если фокус перескочет на него — произойдет скрол страницы. Но если вызвать preventDefault — то скрола не будет.
Другая проблема что порядок таббания отличается от перехода по элементам стрелками(VioceOver), что (конечно же) может все сломать и с этим уже бороться бесполезно.
А вот проблема с tabIndex раскиданным по странице с точки зрения порядка обхода — и не проблема вовсе — github.com/theKashey/focus-lock/blob/master/src/focusMerge.js
1. Во первых aria-busy придуман не для этого. Основной контент надо именно «прятать», для чего нужен aria-hidden. И это относится исключительно к пункту 3.
2. А вот пункты 2 и 3 различать не надо. Есть два события — focusIn, когда фокус куда-то пришел, и focusOut, когда он откуда-то ушел.
Большинство библиотек агрятся на попытку фокуса покинуть ловушку, те focusOut, где новый элемент будет записан в relatedTarget. При этом ловушку в любом случае можно покинуть уйдя в адресную строку браузера, и на этом все сломается. Выбрался — значит свободен.
Плюс focusOut — его можно(и нужно) вешать на свою ноду.
К сожалению, так как это не очень работает, требуется вешать хэндлер на focusIn глобально на документе. Теперь, когда что-то за пределами ловушки получает фокус — можно будет этот фокус взять и положить обратно.
Ну а в итоге требуется вешать события и туда и туда.
И самое главное — НИЧЕГО кроме операций с фокусом делать не надо. Никакие keyboard/mouse/touch events.
Тоже самое относиться к предложеным фокусным ловушкам по краям основной. Главный поинт в том, что эти ловушки должны быть за пределами, а не внутри. И исключительно чтобы между началом/конца документа и модалом был что-то таббательное.
И в таком случае их вообще можно не включать в состав библиотеки — focus-lock/dom-focus-lock не могут менять верстку.
В общем KISS в полной красе.
В общем случае с самого первого или самого последнего можно выйти во внешний мир и/или просто начать не правильно работать.
Пофиксил react версию focus-lock просто добавим элемент с tabIndex=1 за пределами ловушки, и обновил ссылки на примеры в статье — теперь работают секси.
PS: Я вообще не совсем уверен откуда я взял старую ссылку — она использует старую версию библиотек. В общем спасибо за комментарий.
Честно говоря достаточно не типичный набор для современного программиста, ведь хабратопик за публикацию не считается, как и комменты к нему не относятся к рецензиям, но вопрос в другом:
Насколько все это формально, и может ли переходить колличество в качество.
Австралии, где я сейчас нахожусь, требуется только образование и опыт работы. На колличество патентов, звезд на гитхабе и профессиональный уровень вообще — глубоко фиолетово.
github.com/bem/webpack-bem-loader
Декомпозиция и изоляция — вечные друзья и спутники программиста.
Есть CSS driven by CSS — это Tachyons/Turrent и другой atom/functional CSS. Где CSS-а практически нет, зато в html.
И есть CSS-in-JS/ShadowDOM который разными путями немного исправляет генетику CSS+HTML и к нему следует применять немного другие подходы, потому что НЕ нужно именовать что либо по BEM-методолигии так как нет _необходимости_.
>Тем кто хочет идти работать в Y, думаю, точно стоит вчитаться и попробовать
В Яндексе есть много мест где никакого БЕМа нет.