Меня вот тоже интересует этот вопрос. Чего всем так этот мак упёрся рогом. Что он для написания кода делает такого, что не может обычная пекарня с линуксом. Ну или на крайняк хороший ноут, коих полным полно
Robur, очень врятли. Просто возьмите и напишите это на чистом js, в случае чаво, просто спросите у них, а как иначе??? Если они поведуют нам это, будьте любезны, напишите тут. Мы все очень внимательно послушаем
Иван Симонов, ничего не нужно знать особенного. Просто послать ajax запрос к этому файлу ну и правильно указать путь к нему. Дальше просто выведите в консоль результат этого запроса. Либо просто посмотрите в вкладке network на этот запрос и там посмотрите на результат. Дальше исходя из данных действуете на своё усмотрение
Froggyweb, природу я +- понял, решение простое, не нужно хранить слайдер внутри flex родителя.
В кратце причина слудующая, при инициализации слайдера, js расчитывает размеры слайдера. Так вот внутри flex родителя js начинает толи глючить, то ли что, и рекурсивно начинает увеличивать размеры слайдера. Поэтому просто не нужно вставлять его в такой контейнер. Иногда можно воспользоваться абсолютным позиционированием, это помогает или фиксированным размером слайдера.
midarovrk, ну сама строка то у вас правильно формируется? Может в ней есть ошибки какие?
Попробуйте сначала проверить, 1 итерацию и запустить её как обычный код.
В любом случае, то, что вы делаете, это полная дичь и решить вопрос можно легко обычным кодом, а не "генерацией"))
Игорь, Когда я изучал подобные вопросы, т.к. спорил с селшниками, все статьи, что были в целом говорят и можно и не можно. + есть семантика, тег section должен иметь заголовок.
После я решил самолично изучить разницу в сайтах. Заголовками h нужно выделять лишь те заголовки, которые имею прямую функциональность и важность для контента. Уровень заголовка h1 ... h6 лишь выделяют иерархию, вложенность, как оглавление.
Если выделять в h1 всё, что не приколочено, наверно это не правильно, но яндекс выделил функциональные части, значимые, это статьи, важные разделы и т.п. Что для меня как бы логично.
А если выделять наши преимущества в h1 или прочую муть, которой наполняют сайты визитки, то я думаю это глупо.
Бездумно не нужно этого делать, поэтому я пришёл к мнению, что ребята из гугла и яндекса не тупые, там очень много умных ребят. И уж наверняка они всё же знают, как работают их поисковики.
Или всё моё мини расследование чушь и это просто заговор.
Антон Антон, Если только нужно все анимации делать последовательными. Но такая задача 1 на 100.
Обычно делаю появление элементов при их попадании во вьюпорт. А в вьюпорте может быть несколько свершенно разных элементов. Если на то пошло, то для некоторых элементов в директиву можно передать delay.
Вы предлагаете поочерёдно анимировать элементы относящиеся к 1й группе, тогда вы правы. Нужно просто ждать окончания предыдущей анимации и запускать следующую. А тут во время скролла, от чего я и сказал именно директиву.
Gimir, да никаких там нет проблем. Что вы судите по 1й лишь статье. К тому же, в статье кроме как про какие-то мистические проблемы SSR больше ничего не сказано. Берите и работайте, главное, изучить доку, как я сказал, он во много отличается от простого vue проекта.
stepa90, 100 000 не так уж и много. Вон, вк несколько миллионов если не десяток. И никаких json файлов там нет. На пропускную способность играет очень много иных факторов.
Я высказал вам своё мнение на этот счёт. Вы можете быть с ним не согласны.
Хранение в json глупая и до сих пор не понятная мне затея. Взять из базы и положить в json??? Когда для этого есть серверный кеш. К тому же, этим кешем можно управлять.
Кеш на сервере это те же самые файлы, только в них уже полностью обработанная информация лежит. Только возьми. Т.е. в базу идти не нужно, делать выборку, формировать её, обрабатывать и т.п. Всё уже в кеше готово, только возьми.
Вопрос синхронизации остаётся открытым при вашем подходе.
stepa90, Глупости. Вы только всё усложняете мнимыми оптимизациями. Просто сервер кеширует запросы, всё! Клиент запрашивает и моментально получает свои данные. Не усложняйте себе жизнь. Вы никак не выиграете от этого.
Самый простой пример. Есть список, есть создание элемента списка. Вы создали список, отправили беку запрос, он его принял. Как решать вопрос с тем, что бы отобразить в вашем "закешированном списке" новый элемент?
Вы скажете, ну, просто запушить в массив новый объект и вы будете правы, но ваш элемент не полный, в нём, например может не хватать полей, которые создает бекенд, например id, при помощи которого можно делать какие-то запросы например и т.п.
На мой взгляд клиент не должен у себя кешировать данные, даже которые редко редактируются. Файлы, да, данные нет! Иначе случиться так, что у одного пользователя одни данные, а у другого другие.
