Или вы предлагаете просто распилить весь интервал на M фиксированных кусоков?
да, именно так. Я, собственно, и написал, что это будет хорошо работать не всегда. Если у объектов длинные интервалы, то в большинстве кейсов точка будет попадать на много объектов (количество, сравнимое со всем списком), и смысла что-то придумывать вообще нет.
Но если автор озадачился вопросом, то возможно у него предполагаются маленькие выборки на точку.
В новом способе ты создаешь здоровенный "массив с дырками". Встречал мнение, что это деоптимизирует, но почему - не совсем понятно. В любом случае, это не будет однократным выделением памяти под 100000000 целых чисел, как в случае new Int32Array(size)
Там в компоненте DivWithBug нет перескакивания курсора, потому что при печатании хотя и делается ререндер, но в children компонента < div contentEditable > передается один и тот же текст "Edit me.". Соответственно, когда после ререндера VDOM применяются изменения к DOM, то в этот див не ставится новое содержимое, т.к. у старого и нового VDOM оно не поменялось (DOM меняется точечно в тех местах, где обнаружились расхождения виртуальных деревьев, в этом вся суть).
Если сделать содержимое дива управляемым - вместо текста "Edit me." поместить туда {input} - то баг имеет место. Ссылка
Как именно реакт заменяет текстовое значение, сказать не могу, но положение курсора при этом не сохраняется, и реакт не заботится специально, чтобы его сохранить.
WbICHA, то что тип "любое значение, кроме null и undefined" назвали "{}" - это кривой нейминг. Но раз уж назвали, то надо придерживаться иерархии, я так думаю.
WbICHA, пробовал этот вариант, там внутри функции checkWithError параметр n будет "числом и массивов строк", соответственно все свойства массива добавляются в n (выходит черт знает что в автокомплите), и к тому же n можно присвоить в массив.
А тип ErrorMix "почти ничего" не добавляет, у него только поле-симбол, недоступное снаружи и уникальное.
здесь в check всё нормально, внутри CheckWithError аргумент оказался числом или строкой, а "попытка всё исправить" в checkWithError2 закономерно возвращает нас к never, см. последнюю строку
Kentavr16, можно ещё в такую сторону поэкспериментировать
здесь предполагается, что функция проверяет тип входных данных, и если он не соответствует проверке, то превращается в never, как следствие будет ошибка TS. Вариант подходит, если ты будешь передавать в функцию числовой литерал.
Но тоже непонятно, насколько это полезно. Возможно, тебе всё это ни к чему, если гарантируется, что в поле lat значение попадет только через метод setLat. Ты можешь просто создать класс Earth, в котором будет геттер/сеттер для lat, тогда проблем не возникнет - в сеттере проверка не допустит лишнего. Тогда и тип не нужен.
Но если автор озадачился вопросом, то возможно у него предполагаются маленькие выборки на точку.