Смотрите, если вам нужен глобально уникальный идентификатор, то концептуально пути 2:
1. Это централизованная сущность, которая считает и хранить все идентификаторы в соответствии с вашими требованиями.
2. Это алгоритм, который всегда генерирует рандомное число.
Если вам важно видеть порядок и видеть наносекунды, то могу предложить какой-то вариант генерации в духе текущий таймстамп с наносекундами и в конце дописать 2-3 рандомные цифры, чтобы если вдруг совпали наносекунды, то все равно была соблюдена уникальность.
А сам уникальный ID можно на уровне postgres генерить с помощью триггеров. Например, вот пример создания триггера и изменения id после вставки записи: https://stackoverflow.com/questions/11125419/creat...
Вам достаточно поменять алгоритм генерации.
Если и такой вариант не подходит, то было бы здорово если бы вы описали более полно что делает ваше приложение и почему предложенные решения не подходят и мы бы могли помочь или перепроектировать какие-то части (если вам не подходят основные способы, то проблема может оказаться в архитектуре), или подсказать решение более точечно.
Евдоким, в целом, у expo, конечно есть свои недостатки, в которые мы просто не уперлись, поэтому он нам и подошел. Всегда есть третья альтернатива — react-native cli. Каждый инструмент под свои нужды)
Роман Александрович, Дело было в том, что в библиотеке, которую вы хотели подключить, содержались нативные модули, которые expo не поддерживает? Да, должен признать, мы в них необходимости не испытывали и поэтому у нас Expo прижилось.
Евдоким, нет, не сравнивали, мы делали небольшие приложения и вес был несущественный. Но, конечно, вполне может быть, за выигрыш в скорости разработки и поддержки надо платить.
Роман Александрович, вы точно работали с последней версией? вообще будто с вами про разные продукты говорим) то о чем вы пишете мы тоже проходили, но последний раз это было около года назад, потом все обновилось и больше проблем не было)
Мдауш, мистика. А если не на десктопе, а в веб-версии такой же эксперимент провести? Я ставлю на то, что это какой-то баг новой версии приложения, её недавно выкатили и многие уже на неё жаловались, у людей даже макеты пропадали. Попробуйте всё то же самое в веб-версии проделать, может другой результат будет.
Я хотел увидеть, что она не абсолютно прозрачная и получить дополнительный контекст. Действительно странно, остается только проверять всё ли нормально с фреймом к которому сетка применена и точно ли все слои находятся внутри этого фрейма, а не лежат поверх.
Так же странно, что с другими макетами все нормально, можно попробовать отловить в какой момент сетка пропадает, попробуйте снова создать новый фрейм и переносить не всю работу в него, а кусками, возможно получится увидеть из за чего все ломается и тогда станет яснее.
Владимир, довольно запутано и неподдерживаемо. Не думали отказаться от jquery и переписать все на какой-то современный фреймворк? выглядит так, будто вы его в коде как раз пытаетесь изобрести :) проблема с инпутом решилась бы сама собой
возможно дело как раз в этом вашем инжекте инпутов(что бы это не было). Так или иначе, недостаточно данных, чтоб сказать точнее. Попробуйте, как вам уже советовали, собрать песочницу.
dom1n1k, дело в том, что обе эти функции являются декораторами — они принимают на вход какую-то другую функцию(допустим f), вместе с специальными параметрами, после чего возвращают уже измененную функцию(допустим f2). Throttle и debounce предотвращают неоправданно частый вызов f. Например, это актуально в случаях, когда мы хотим что-то делать при перемещении мыши или при скролле.
На демке показан пример именно с перемещением мыши. Отображены 3 графика, в первом случае, на событие перемещения навешана функция f. Длинные штрихи появляются когда функция f срабатывает. Следовательно на двух графиках ниже видно, как throttle и debounce фильтруют ненужные вызовы f. В случае с throttle видно, что если без остановки двигать курсор, то вызов стабильно происходит через определенный период времени(который был передан в параметрах при вызове декоратора).
В случае с debounce логика совсем другая. После каждого вызова f2 запускается таймер, который считает время до следующего вызова, если вызова не происходит за период времени(который был передан в параметрах при вызове декоратора), то происходит вызов f, при вызове f2 таймер сбрасывается.
andrei_pro, Так до конца и не понятно, что у вас происходит при перетаскивании элемента —
1. его x и y зачем-то записываются vuex — зачем?
2. На что влияют эти координаты? Они привязаны к каким-то другим элементам? если так, то каким образом они на них влияют? через какие css свойства?
Сложно сказать из представленного кода, что можно оптимизировать, т.к. не известно, как вы потом с x и y работаете. Если скинете пример, может и получится дать конкретные рекомендации
ch-aqwer, я так вижу у вас и prettier используется? Судя по всему, вам его нужно подружить с eslint, если он еще не подружен и все заработает как надо.
Первое, что удалось нагуглить по теме: https://thomlom.dev/setup-eslint-prettier-react/
1. Это централизованная сущность, которая считает и хранить все идентификаторы в соответствии с вашими требованиями.
2. Это алгоритм, который всегда генерирует рандомное число.
Если вам важно видеть порядок и видеть наносекунды, то могу предложить какой-то вариант генерации в духе текущий таймстамп с наносекундами и в конце дописать 2-3 рандомные цифры, чтобы если вдруг совпали наносекунды, то все равно была соблюдена уникальность.
А сам уникальный ID можно на уровне postgres генерить с помощью триггеров. Например, вот пример создания триггера и изменения id после вставки записи: https://stackoverflow.com/questions/11125419/creat...
Вам достаточно поменять алгоритм генерации.
Если и такой вариант не подходит, то было бы здорово если бы вы описали более полно что делает ваше приложение и почему предложенные решения не подходят и мы бы могли помочь или перепроектировать какие-то части (если вам не подходят основные способы, то проблема может оказаться в архитектуре), или подсказать решение более точечно.