Артем
С нами с 15 октября 2017; Место в рейтинге пользователей: #1673 часа назад
Еще снова вернулась проблемка, после выбора способа доставки почтой РФ — появляется стоимость доставки, но она «прилипает» и не исчезает после переклю...
Расчет стоимости доставки msRussianPost 11
6 часов назад
Лучше деинсталировать и установить новую версию. Там полностью переписан JS.
ms_CDEK2 пропал? 5
7 часов назад
Фильтрация как правило предполагает точное совпадения значений, а тебе нужен поиск.
mFilter2 фильтрация tv 1
8 часов назад
Все исправилось, после замены на 'parents' => $_modx->resource.id
Помогите найти ошибку в шаблоне, теги 13
Вчера в 09:31
А кто подскажет, как в форму Создания/Редактирования ресурса, через ms2Form, добавить возможность выбирать несоклько параметров в одном TV?
Ну то-ест...
Создание ресурсов из фронтенда сайта, зарегистрированными пользователями. 4
Вчера в 08:53
если правильно понял то так
{set $rows = json_decode($_modx->resource.constructor_block, true)}
{foreach $r...
getImageList. Вывести вложенный migx на fenom 1
Вчера в 08:43
Подскажите, если на странице будет две формы, они будут работать? К примеру reCaptchaV3 этого сделать не может, нужно через костыль в виде скрипта, ко...
YaSmartCaptcha - защитите ваши формы от спама умной капчей от Яндекс 5
20 ноября 2024, 16:25
В сниппете rcv3_html достаточно отложить загрузку через setTimeout (хотя кто-то делает через onClick). Не думаю что мой вариант самый правильный и что...
reCaptcha v3 - отложенная загрузка 1
19 ноября 2024, 10:51
Решил свою проблему через имя пользователя, но хотелось бы через права пользователя «Неограниченные права»
<?php
/**
* Системное событие OnMan...
Редактирование контекста в мультидоменном сайте 1
19 ноября 2024, 09:09
Спасибо, тоже очень интерестное решение.
Помогите советом, по реализации платных одноразовых услуг на сайте. 4
Достаточно открыть тред недельной давности и посмотреть на споры в комментах между «дублирует» и «не дублирует».
Если бы эти условия были четко прописаны, то никто не спорил.
Где та грань, при которой «очевидно», а где та, при которой «спорно», а где та, при которой «всего скорее нет»?
Я даже процитирую свои слова, чтобы не повторять это снова.
Помимо этого, разработчик может сначала придумать дополнение A, повторяющее функционал уже имеющего на 30%, а затем дополнение B, повторяющее функционал другого компонента на 60%. В таком случае ему придется с каждым дополнением бежать в поддержку и объяснять на пальцах, в чем он повторяет, а в чем нет.
Это неудобно.
Допускаю, что это мое субъективное мнение, но лично я бы этим заниматься не стал.
Этот список касается на 99% только оформления, кода и вот этого всего, а про пересекающийся функционал там только 1 строчка, которая не вносит никакой ясности.
В общем, мой посыл в том, что было бы хорошо раскрыть этот пункт и внести больше ясности, которая позволила разработчикам меньше ломать голову и больше заниматься разработкой, а не бюрократией и переписками с техподдержкой.
Достаточно сравнить этот вариант с каким-нибудь конкретным списком из N пунктов, где ясно и четко прописано, в каком случае дополнение будет отклонено.
Понятное дело, что все равно будут пограничные спорные случаи, которые придется рассматривать на этапе модерации, но сейчас ясности, на мой взгляд, мало — вопрос выше остался без ответа именно по этой причине.
На мой взгляд, политика в отношении подобных вещей должна быть кристально ясной и четкой, как два пальца, а не «мы рассматриваем каждое дополнение индивидуально».
Поставьте себя на место разработчика, который хочет написать новое дополнение, но оно пересекается с уже существующим по функциональности. Ему что, идти в поддержку и рассказывать о своих еще не реализованных идеях? Политика должна такие вещи однозначно предусматривать заранее, чтобы разработчик уже знал на 100%, пройдет его дополнение или нет.
Иначе зачем ему вообще тратить свое время, если его дополнение может пройти, а может и не пройти? Это же не лотерея какая-то, а магазин дополнений, у которого, еще раз повторюсь, должны быть однозначные, четкие и понятные правила.
В любом случае, речь здесь идет о том, что это простая задача и она должна быть решена на уровне пакета, а не на уровне «ну как повезет».
Если второе, то объясняю на пальцах:
Я уже не говорю о том, что уже есть сотни готовых резолверов в других пакетах, которые делают примерно то же самое.
Так где тут «проблемная задача»?
Тогда не представляю, кому еще может понадобиться твое творение, если не новичкам.
А больше тебе ничего не нужно сделать?
Я бы понял твое предложение, если бы пакет был полезным/удобным и решал бы какую-нибудь задачу, но у новичков с ним возникнет больше головной боли, чем пользы, поэтому не особо понятно, с чего бы там взяться «счастью».
Тон оформления твоего «пакета» вызывает впечатление, что тебе лишь бы поговнокодить. Извиняюсь, конечно, за прямоту, но вот такое впечатление у меня.
Если ты выкладываешь пакет, то будь добр потратить время и соответствующе его оформить, а не вырезать бесполезный кусок кода со своего проекта. Это, как минимум, дурной тон по отношению к пользователям, которые потратят время на твой пакет в попытках завести его у себя.
В чем проблема создать эти ресурсы и сохранить их id динамически, это непосильная задача?
Жаль минус уже поставить нельзя, влепил бы два сразу.
Неправильно, потому что пакеты для фронта никто не пишет на CommonJS модулях, они ж не на ноде работать будут, а в браузере.
У них же прям первой строкой написано:
Естественно, ведь npm — ничто иное, как node package manager.
Другой вопрос в том, что разные пакеты решают разные задачи. Chalk, например, создан для терминала и к фронту (браузеру) не имеет отношения, а условный vue-select, наоборот, не имеет отношения к серверу и должен использоваться исключительно в браузере.
«Деления» нет, есть разные пакеты для разных задач. Просто гуглишь пакет и смотришь, для чего он и где (как) используется.
Ровно как и фирме, в которой ты работаешь. Тебе здесь пишут это уже не первый раз, стоит задуматься)
Или тебе интересно ковырять весь этот говнокод, покрытый пылью и плесенью?
Ну дык и пусть страдает, его ж проблемы, а тебя вряд ли кто-то заставляет под дулом пистолета заниматься вот такими кадрами.
Повторю еще раз: беги оттуда, да не оглядывайся назад.
Говорят, что за это нужно платить. Это же нужно заказчику и его бизнесу, а не конкретно тебе. Значит заказчик должен заплатить за свою хотелку. Если его сайт старый и не подлежит адекватной поддержке, значит нужно заплатить за новый сайт. Если не хочет — до свидания.
Уважать себя нужно.
Тут вопрос личных предпочтений — если тебе интересны CMS и нравится работать на условном битриксе, то естественно, что тебе не нужен ни React, ни Vue, ни Angular.
Но эти сайты никогда не смогут тебе предоставить такой же красивый, динамичный и приятный интерфейс, как условный Vue, например.
Если же тебе не нравится, то нужно бросать это говно и заниматься тем, что нравится, учиться и поднимать свою планку знаний, чтобы делать красивые, быстрые и удобные сайты.
Вопрос денег? Предположу, что за твою работу не платят хороших денег, потому что она рутинная и не требует особых мозговых усилий. Вероятно, джуниор реакт девелопер может получать не меньше, так в чем проблема стать им, если тебе это интересно?
Ради 1 строки вместо 3 тянуть jQuery?
Ну так нужно учить только то, что реально тебе нужно в настоящий момент, а не гнаться за всем новомодным. JS-коммьюнити одно из самых оживленных и здесь каждый день придумывают что-то новое, не нужно хвататься за все подряд, если тебе это не нужно.
Ничего не мешает сначала потихоньку подучить язык, затем взять какой-нибудь один фреймворк, который тебе импонирует больше всего, и погрузиться только в него.
Совершенно разные вещи. Здесь нет ни слова про «XMLHttpRequest признан устаревшим». Это не более чем рекомендация, потому что в каком-то светлом будущем у нас действительно будет современный и удобный fetch, но это уже совсем другая история.
XMLHttpRequest не может быть признан устаревшим, если для него нет полноценной замены.
Помимо этого, это вешает на проект тяжелое jQuery-бремя и, вероятно, новый разработчик с более высоким уровнем знаний не захочет браться за старую jQuery лапшу.
Нужно думать не только о «мне так удобно и я так хочу», но и о проекте в целом. Если ты тянешь в проект jQuery, потому что «я так хочу», но на это нет веских оснований, то ты так себе программист.
Как я выше сказал — это говнокод в чистом виде, автор видео имеет довольно низкие знания и любой более-менее нормальный разработчик не будет использовать его разработку, если хоть мельком взглянет на то, что там творится.
Автор молодец только в том случае, если к вопросу подходить с точки зрения конечного продукта, а не с технической точки зрения, но мы как раз говорили о технической.
Напишешь свою обертку? Во-первых, это будет велосипед, за тебя это уже сделали, и всего скорее лучше. Во-вторых, ты потратишь больше времени и сил на ее тестирование, а вместо этого мог бы писать свое приложение.
Возьмешь готовую обертку над fetch? Ну так и чем это, по-твоему, будет отличаться от axios? При этом, если тебе вдруг понадобится сделать загрузку с процентным прогрессбаром, то ты не сможешь этого сделать на fetch и тебе придется как-то выкручиваться.
И тут, наверное, ты потихоньку придешь к пониманию, что лучше все-таки было взять удобный axios и не вставлять себе палки в колеса.
И это я еще молчу про дополнительные удобные фичи типа интерсепторов
Да, над fetch есть обертки, которые тебе и исключение бросят, и .json() за тебя сделают, но процентную загрузку они тебе не дадут без XMLHttpRequest.
Поэтому еще раз повторю, что fetch — низкоуровневый инструмент и пока он не сможет в процентную загрузку, заменить XMLHttpRequest им невозможно.
Я бы с удовольствием предложил авторам реализовать загрузку файла с процентным прогрессбаром на современном и новом fetch.
Это не меняет ровным счетом ничего, потому что fetch все еще остается неудобным и обрезанным по функциональности, тем более, что обернуть XMLHttpRequest в промис — это несколько строк.
jQuery — устаревшая и ненужная библиотека, потому что:
а) 95% функционала из jQuery — это сахарок, который в современном js не нужен;
б) jQuery-обертки медленные, и это было бы простительно, если бы они были полезные, но это не так;
в) в современном js мире рисуют интерфейсы через React/Vue/Angular, в котором не работают с DOM напрямую. Напомню, что jQuery делает именно это — работает с DOM напрямую. Поэтому скрещивать любой из перечисленных фреймворков и jQuery — это говнокод в чистом виде.
г) для оставшихся 5% функционала из jQuery придуманы отдельные инструменты, куда более удобные, быстрые и функциональные. За примером далеко ходить не надо — тот же axios.
Подскажи, как ты собираешься обойтись без axios, если ты хочешь работать с api в условном Vue?