forspamonly2

я не очень понял чего вы тут хотели, но чтобы "отключать функцию" после первого срабатывания можно .on заменить на .one

api.jquery.com/one

вспомнить школьный курс геометрии?

выводить картинку побольше, чтобы хватило на вырезанные области. помножив исходный размер по формуле вписанного квадрата на корень из двух :)

https://codepen.io/anon/pen/NoNpzZ

а ещё можно посчитать минимальный размер и смещение для каждого угла, но это уже задачка со звёздочкой.

карточки в левом списке у вас перерисовываются потому, что каждая из них присоединена к редуксовскому хранилищу. точнее, перерисовываются редуксовские обёртки, которые Context.Consumer - вы их наверняка видели в реактовских девтулзах.

сам компонент действительно по умолчанию pure, но это работает как: редуксовская обёртка ловит изменение хранилища, получает новый store, вызывает ваш mapStateToProps и перерисовывает обёрнутый компонент с новыми props. а уже после этого отрабатывает shouldComponentUpdate от внутреннего PureComponent, понимает что ничего не поменялось и сам обёрнутый компонент уже не перерисовывается.

глобально, вам стоит сделать карточку тупым (презентационным) функциональным компонентом - принимать в нём на отрисовку готовый объект данных карточки, а получать и передавать его из connected компонента списка.

убеждённый сторонник второго варианта.

код пишут чтобы читать.

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

любое разбирательство в малознакомой или хорошо забытой кодовой базе начинается с локализации проблемы с точки зрения пользователя (в подавляющем большинстве случаев, это значит в интерфейсе), а потом уже попыток понять "чем он это сказал". и простой поиск текста по исходникам во втором варианте позволяет сразу просмотреть списком все места где этот текст встречается, а в первом варианте вынуждает ещё искать по одному вхождения каждого из ключей.

особенно отвратительно, когда первым выриантом локализуется форматная строка от какого-нить принтф: какие-то параметры передаются, а как трактуются - не выяснить без рытья по ресурсам.

сама необходимость придумывать осмысленные ключи для каждой строчки в первом варианте - это то ещё развлечение. одно из двух признанных сложнейших дел во всём программизме (классика: именование вещей и инвалидация кэша) внезапно увеличивается на количество всех строчек в софте.

вот что у первого варианта лучше, это поддержка со стороны инструментария. всякие ide табличками ресурсы на разных языках показывают, существуют удобные онлайновые средства для колективного перевода, и так далее.

однако, на практике это всё не работает, потому что перевод софта - это процесс с деятельным участием специалистов заказчика (они же всегда лучше знают как правильнее, даже если сами ни в зуб ногой), а их юридическому отделу ide не подсунешь, и согласовывать их шеф будет по конторскому документообороту, в крайнем случае распечатку. в общем, в реальных проектах между конторами гоняется файлик со строчками софта в ёкселе. который конвертируется в ресурсы и обратно какой-нить самопальной тулзой, а потом долго, с матом, вручную мержится с ресурсами в софте, потому что недопереводчики очень любят как попало править и то, что им поручили, и что-нибудь ещё, на остальных языках (типа, "в той формулировке красиво не переводится, лучше пусть так будет").

и это приводит к основному минусу второго подхода: когда правится текст на основном языке, надо будет ещё поправить все вхождения этой строки по всему софту. впрочем, стандартные инженерные практики (dry, обобщение повторно используемого кода) успешно препятствуют слишком уж большому количеству повторений одного и того же в разных местах.

насчёт разных переводов одной фразы - да, такое бывает, но реально очень редко. настолько редко, что какой-нибудь костыль с добавленным пробелом и комментарием зачем он там нужен, субъективно не кажется чем-то, что следовало бы вместо этого обрабатывать на уровне механизма. я буквально пару-тройку раз могу вспомнить за 20 с лишним лет написания софта для местного рынка. а я в казахстане живу, тут всё на нескольких языках и это закреплено законодательно.

как я понимаю, вы именно на ванильном жабаскрипте пытаетесь, поэтому библиотеки и фреймворки советовать не буду.

новый элемент списка я бы вам советовал всё равно сделать в виде шаблона, хотя бы простого жабаскриптовского многострочного литерала. вот текст самой тудушки в нём лучше скриптом прописать в innerText, чтобы не эскейпить руками.

вместо того, чтобы на каждую созданную тудушку цеплять все обработчики событий, лучше обработку делегировать - повесить их один раз на сам список. а то, какую кнопку какой конкретно тудушки кликали, общий обработчик может выяснить по event.target.

кнопки "Изменить" "Удалить" лучше показывать не скриптом, а цсс.

ну и самое главное, вы фактически модель данных держите прямо в хтмл элементах. это приемлемо работает только на примитивных примерах, вроде вашего. в большинстве реальных случаев куда проще иметь разделение на модель данных, которыми оперирует скрипт, и их отображение в виде хтмл. почитайте про паттерн model-view-controller.

не надо ничего резать на отдельные картинки.

у css3 анимации можно указать фиксированное количество шагов.

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

как тут: https://codepen.io/bsl-zcs/pen/lpaGv

а пять кадров - это просто очень короткая анимация, на пятую часть секунды. на должной скорости вполне плавно выглядит.

читайте про CSSOM. https://developer.mozilla.org/en-US/docs/Web/API/C...

если знаете какая по счёту таблица стилей и правило в ней (судя по селектору, вас какой-нибудь reset беспокоит, который всегда первый), то всё просто:
document.styleSheets[0].deleteRule(0);

если не знаете, придётся перебирать и искать:

let i = [...document.styleSheets[0].cssRules].findIndex(r => r.selectorText==="*")
document.styleSheets[0].deleteRule(i);