Кто-нибудь знает, когда css grid можно будет пользоваться в публичных проектах?

НИКОГДА АХАХАХАХА

Представляю 2035 год: Проект на ES2036, React 50, и в требованиях поддержка IE6

поддержка ES6

Ы

А так как в природе все циклично, верстка -- табличная

В 2036 году реакт у тебя в мозгах беспроводные импульсы будет посылать

Или нас всех смоет КЕМ

В 2036 году реакт у тебя в мозгах беспроводные импульсы будет посылать

ммм, вебкит в мозгу

Кто-нибудь знает, когда css grid можно будет пользоваться в публичных проектах?

не скоро

Или нас всех смоет КЕМ

"КЕМ" ?

не скоро

Почему не скоро? Они же уже почти готовы, не? А остальное зависит от проекта.

Почему не скоро? Они же уже почти готовы, не? А остальное зависит от проекта.

а поддержка? но вообще по-моему уже сейчас можно использовать, только зафаллбэчить правильно

В 2036 году реакт у тебя в мозгах беспроводные импульсы будет посылать

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

а поддержка? но вообще по-моему уже сейчас можно использовать, только зафаллбэчить правильно

http://caniuse.com/#search=grids

http://caniuse.com/#search=grids

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

http://lurkmore.to/%D0%9A%D0%95%D0%9C

а поддержка? но вообще по-моему уже сейчас можно использовать, только зафаллбэчить правильно

они не фоллбечатся

они не фоллбечатся

пфф, ты недооцениваешь возможности костыльно-ориентированнйо разработки

пфф, ты недооцениваешь возможности костыльно-ориентированнйо разработки

нет

пфф, ты недооцениваешь возможности костыльно-ориентированнйо разработки

круто, когда к костылям начинаешь делать еще подпорки ))

нет

воообще в случае убогого SPA которое рендерит только на клиенте можно задетектить же гриды и потом подгрузить нужный css

воообще в случае убогого SPA которое рендерит только на клиенте можно задетектить же гриды и потом подгрузить нужный css

а что ты будешь делать без них?

можно и без относительно SPA, просто @supports медиа выражение

а что ты будешь делать без них?

флексы, флоаты

с другой стороны - зачем юзать гриды когда всё равно придётся писать на флексах

флексы, флоаты

не получится даже 80% воспоизвести

с другой стороны - зачем юзать гриды когда всё равно придётся писать на флексах

ага

не получится даже 80% воспоизвести

да, для нормального воспроизведения надо будет отдавать не только другие стили, но и другой штмл

зато "смотрите у нас поддержка гридов!"

бесценно

Кого?

Гридов

Професианалы!

Ой.

Профессионалы.

Сижу и что-то закипаю, подскажите-ка.

Был матрица двумерна. Стала линейна.

Там, конечно не NaN в примере, а undef., просто nan покороче и влез в клетку.

Вопрос: как корректно поступить с линейным массивом?

Я программист а не математик(

Может кто из ребят подскажет.

Как проснутся.

Ты хочешь превратить матрицу в массив?

Или это задача

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

При выходе за пределы двумерного легко отслеживается через undefined, а вот в случае с линейной происходит сдвиг.

И данные выходят некорректны.

Туплю. Что-то упустил. Сижу вспоминаю.

Можно напихать проверок на длины, но тогда код усложнится даже более, чем с двумерными проверками, вот что смущает.

А чем плох двумерный массив? зачем делать одномерный?

Скорости. Типизированный, не просто массив.

Предполагаются бинарные матрицы до нескольких гигабайт.

а избежать выхода за пределы никак?

там же чётко 9 я так понимаю

В линейном? Можно конечно, если нагородить условий проверок длинн.

Пример лишь 9, да.

а избежать запросов выходящих за пределы никак?

Вот и загвоздка. Классически стоит просто «навтыкать» возможных проверок, а это не просто усложнит код, добавит бòльших задержек в алгоритме.

я никак не пойму - почему нельзя обращаться куда надо и не лезть за пределы?

Мб будет понятнее, если уточнить, что изначально данные представлены в сыром виде, т.е. буфером, а typed arr. лишь представление.

ну тогда вроде только проверки помогут

ERROR: S client not available

Вот и загвоздка. Классически стоит просто «навтыкать» возможных проверок, а это не просто усложнит код, добавит бòльших задержек в алгоритме.

Открой уже для себя операции с массивами в lodash)

Я уж не говорю про вуду деструктурируемого присваивания)

const flatArray = [...array2D]

Что еще стоит знать, кроме операций с массивами?

В lodash.

Ну хз, по обстоятельствам же, ты видел сколько в нем всего)

Вот и спрашиваю, чтобы время с пользой потратить. Всю пока освоишь.

Просто вместо гугла сперва искать в лодашь

Хороший вариант.

Работа именно с коллекциями это главная задача _

Зачем lodash, когда завезли es6?

Тебе пока с методами массива освоиться будет уже хорошо) Не знаю, тот же reduce понять, reject, flatten

Он же не работает с типизированными массивами?

В ес6 есть forEach по проперчить объекта ?

Лишняя библиотека ==> лишние операции.

Или может поиск значения по пути к нему в объекте ?

Зачем lodash, когда завезли es6?

Если бы завезли...

В ес6 есть forEach по проперчить объекта ?

Object.keys(obj).forEach

Библиотека? Ты из 2000х?

Если бы завезли...

Все что в lodash.

Лодаш раздроблён на микро компоненты

Object.keys(obj).forEach

Я о значениях

пригодился метод Omit

Ребята, я ж говорю, на счету каждое условие.

reduce для объектов

больше ничего

Хз, ты не придумаешь ничего лучше

Ребята, я ж говорю, на счету каждое условие.

Так там оптимизация есть.

Велосипед девелопмент

В js и каждая секунда? Жди асамблер.

Велосипед девелопмент

Вот вот. Одни костыли, лодаши.