Программирование, т. 7

like za staraniya

Del

​

ладно забейте, это я пригорел от вебгля, все нетакуж плохо и даже хорошо

Бля я чет на работе схожу с ума с ебучей таблицей

Кароче таблица с папками, внутри которых могут еще дополнительные уровни (без ограничений на количество уровней нестинга)

Ну и внутри уровней собственно сами элементы

Все уровни+элементы рендерятся как строки, + у них есть чекбоксы, которые должны воздействовать на чекбоксы родителей/детей. Ну типа в сабгруппе 2 элемента, оба элемента чекнул - чекбокс сабгруппы автоматом должен чекнуться. И так далее

Дак вот, эту всю хуйню на изичах запилил, рендеринг дерева рекурсивно вниз по ветвям, чекбоксы с двойной рекурский (вначале вниз по детям, затем вверх по родителям, с оптимизациями и так далее).

Вот даже есть гифка 2х недельной давности, там еще устаревший интерфейс, в котором тяжелее понимать где сабгруппы/сами элементы, сейчас все выглядит лучше

Дак вот, собственно к делу. Теперь ко всему этому надо прикруть логику "прятанья" (hiding) датасорсов, и их добавления в группы.

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

В итоге получается такая хуйня, что прежде чем рендерить дерево, я должен пройтись по всему дереву СНИЗУ вверх, дабы понять, надо ли мне прятать саб-группы/группы или даже целые токены, на основе статусов детей (элементов).

Это тоже решаемо. Но! В группах/сабгруппах могут быть сотни элементов, которые на старте мы не будем все грузить на клиенте, ибо это юзлесс + тяжело для клиента + лишняя работа для бэкенда и бд. То есть моя фронтенд логика теперь еще и должна делать проверку на то, имею я на руках всех детей группы или нет, и соответственно прогонять всю проверку снова при любом изменении данных (будь то подгрузка новых данных, или обновление данных по вебсокету, с соглашения юзера). Ок, звучит вроде все заебисто, но скорее всего после написания пары тройки мозгоебучих функций все будет работать быстро и уверенно.

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

Кароче уеби меня кирпич плз, я с этим таском уже часов 10-12+ думаю, хотя кода тут писать на 1-2 часа от силы (но писать не получается, ибо вначале надо обдумать все самые конченные юзкейсы и обсудить с продакт манагером и так далее).

Не за что

Бля я чет на работе схожу с ума с ебучей таблицей

Кароче таблица с папками, внутри которых могут еще дополнительные уровни (без ограничений на количество уровней нестинга)

Ну и внутри уровней собственно сами элементы

Все уровни+элементы рендерятся как строки, + у них есть чекбоксы, которые должны воздействовать на чекбоксы родителей/детей. Ну типа в сабгруппе 2 элемента, оба элемента чекнул - чекбокс сабгруппы автоматом должен чекнуться. И так далее

Дак вот, эту всю хуйню на изичах запилил, рендеринг дерева рекурсивно вниз по ветвям, чекбоксы с двойной рекурский (вначале вниз по детям, затем вверх по родителям, с оптимизациями и так далее).

Вот даже есть гифка 2х недельной давности, там еще устаревший интерфейс, в котором тяжелее понимать где сабгруппы/сами элементы, сейчас все выглядит лучше

 

 

 

Дак вот, собственно к делу. Теперь ко всему этому надо прикруть логику "прятанья" (hiding) датасорсов, и их добавления в группы.

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

 

В итоге получается такая хуйня, что прежде чем рендерить дерево, я должен пройтись по всему дереву СНИЗУ вверх, дабы понять, надо ли мне прятать саб-группы/группы или даже целые токены, на основе статусов детей (элементов).

Это тоже решаемо. Но! В группах/сабгруппах могут быть сотни элементов, которые на старте мы не будем все грузить на клиенте, ибо это юзлесс + тяжело для клиента + лишняя работа для бэкенда и бд. То есть моя фронтенд логика теперь еще и должна делать проверку на то, имею я на руках всех детей группы или нет, и соответственно прогонять всю проверку снова при любом изменении данных (будь то подгрузка новых данных, или обновление данных по вебсокету, с соглашения юзера). Ок, звучит вроде все заебисто, но скорее всего после написания пары тройки мозгоебучих функций все будет работать быстро и уверенно.

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

 

Кароче уеби меня кирпич плз, я с этим таском уже часов 10-12+ думаю, хотя кода тут писать на 1-2 часа от силы (но писать не получается, ибо вначале надо обдумать все самые конченные юзкейсы и обсудить с продакт манагером и так далее).

Хз, элементарно же решается задачка. Всегда всё кликаешь и выбираешь, но при работе с данными делаешь фильтрацию, что чекбоксы для строк, у которых параметр hidden=true не учитываются в бизнес-сценариях. В чём трабла так сделать? Нахуй чо-то высчитывать?   Или я неверно задачку понял Это решение сразу же покроет кейс, когда у тебя этот самый хидден в рантайме вычисляется.

Все что хидден вообще не должны рендерится, они будут рендерится при свиче просмотра (будет кнопочка show hidden, если таковые имеются, и соответственно будет рендерится только таблица со скрытыми элементами).

Ну и как указано выше, геморроя добавляет факт, что у клиента не будет всех данных, большая часть всегда будет не подгруженной (аля load 100 more/load all по клику, а кликать не всегда будут), по-этому логика рендеринга/чекбоксов и функционала hide/assign будет "слегка" усложнятся.

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

Все что хидден вообще не должны рендерится, они будут рендерится при свиче просмотра (будет кнопочка show hidden, если таковые имеются, и соответственно будет рендерится только таблица со скрытыми элементами).

Ну и как указано выше, геморроя добавляет факт, что у клиента не будет всех данных, большая часть всегда будет не подгруженной (аля load 100 more/load all по клику, а кликать не всегда будут), по-этому логика рендеринга/чекбоксов и функционала hide/assign будет "слегка" усложнятся.

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

А если бы ты умел немного в матешу, то решалось бы без рекурсий, а построением обычного алгоритма обхода дерева в ширину Плюс добавить сюда теорию графов и отсекать несвязные куски дерева (которые как раз хидден)

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

так в чем именно проблема, сервер пришлет дату и ты построй таблицу по ней

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

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

Если вы хуйню напроектировали, то не нужно пинять на алгоритмы. Прям чувствую что криворукий архитектор приложил руку Как задачку чуть сложнее попапчика или карусельки нужно сделать, тут же обосрамс

[{
	"name" : "Parent Node",
	"hidden" : true, //If child has hidden=false, hidden-attr should be false
	"children" : [{
		"name" : "Child Hidden",
		"hidden" : true,
		"children" : [{ //Lazy
			"name" : "Super Child Show",
			"hidden" : false
			"children" : []
		}]
	},{
		...
	}]
},
{
	...
}]

 

 

 

За шо мне это?

 

ctrl+alt+L ?

Такое сочетание клавиш у меня не работает

 

intellij idea, keymap: Default

преимущества чего?

интегрированной среды разработки уровня jetbrains

 

 

 

 

За шо мне это?

 

ctrl+alt+L ?

Такое сочетание клавиш у меня не работает

 

intellij idea, keymap: Default

преимущества чего?

интегрированной среды разработки уровня jetbrains

 

Код картинкой же. Как ты его отформатируешь?

 

Все что хидден вообще не должны рендерится, они будут рендерится при свиче просмотра (будет кнопочка show hidden, если таковые имеются, и соответственно будет рендерится только таблица со скрытыми элементами).

Ну и как указано выше, геморроя добавляет факт, что у клиента не будет всех данных, большая часть всегда будет не подгруженной (аля load 100 more/load all по клику, а кликать не всегда будут), по-этому логика рендеринга/чекбоксов и функционала hide/assign будет "слегка" усложнятся.

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

А если бы ты умел немного в матешу, то решалось бы без рекурсий, а построением обычного алгоритма обхода дерева в ширину Плюс добавить сюда теорию графов и отсекать несвязные куски дерева (которые как раз хидден)

 

какая разница рекурсией это сделается или проходом в ширину, лол

вычислительная сложность одинаковая - обход дерева 2 раза

конвертация рекурсии в обход в ширину даст только уменьшение футпринта по памяти

ПС: на ангуляре это бы решалось легко. правда неибу как было бы с производительностью в его новых версиях

 

 

Все что хидден вообще не должны рендерится, они будут рендерится при свиче просмотра (будет кнопочка show hidden, если таковые имеются, и соответственно будет рендерится только таблица со скрытыми элементами).

Ну и как указано выше, геморроя добавляет факт, что у клиента не будет всех данных, большая часть всегда будет не подгруженной (аля load 100 more/load all по клику, а кликать не всегда будут), по-этому логика рендеринга/чекбоксов и функционала hide/assign будет "слегка" усложнятся.

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

А если бы ты умел немного в матешу, то решалось бы без рекурсий, а построением обычного алгоритма обхода дерева в ширину Плюс добавить сюда теорию графов и отсекать несвязные куски дерева (которые как раз хидден)

 

какая разница рекурсией это сделается или проходом в ширину, лол

вычислительная сложность одинаковая - обход дерева 2 раза

конвертация рекурсии в обход в ширину даст только уменьшение футпринта по памяти

 

ПС: на ангуляре это бы решалось легко. правда неибу как было бы с производительностью в его новых версиях

 

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

если я всё правильно понял, то сетим hidden = true, если все дети поддерева тоже hidden

это делается обходом в глубину (dfs)

сделал пример
код: https://ideone.com/N3qJRV

рисуночки:

после прогона dfs:

если я всё правильно понял, то сетим hidden = true, если все дети поддерева тоже hidden

 

это делается обходом в глубину (dfs)

 

сделал пример

код: https://ideone.com/N3qJRV

 

 

 

рисуночки:

 

после прогона dfs:

Вроде же наоборот, если внутри хотя бы один не хидден, то нужно расхиддить все что выше. Типа если на картинке снизу 5 НЕ хидден, то 4 и 2 тоже должны стать НЕ хидден. Но у тебя уровень глубже 2 LVL лезийно грузятся. Условно пользователь не увидит никогда 4, 5, 6, так как 2 уже скрыт, но на деле, он должен суметь увидеть 5.

не знаю наоборот или нет, но если наоброт то инвертировать логику это элементарно

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

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

иначе это невозможно

​Вот вебгл версия, на джаваскрипте выдает под 30 ФПС https://danilw.github.io/cputests/js/opengl_basic.html

​Графон пострадал существенно-в webgl(сравните с видео что я кидал, там С++ опернгл записана), в опенгл есть освещение всей сцены и сложение цетов в "белый" пикселей который друг под другом находятся....в вебгл только пиксели

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

​(последняя сцена с буквами "pd" тормозит нереально, я ее даже в 2 раза линий меньше сделал всеравно макс 10фпс, странно, на С++ было 100+фпс)

если хотите быстрее/медленные меняйте параметр "dotsscale" в джаваскрипте 100 даст в 10 раз меньше точек и лучший фпс, сейчас стоит 1000, можно 10000 и больше ставить

также "rotateradius" шаг точки, чем меньше(меньше 1 и до 0.00001) тем больше точек,чем больше-темменьше точек, тоесть поставив 2 или 3 тут и 100 в верхнем-будет плюс произвдительностиь

это желающим потестить

видюха под 40% нагружается и пара ГБ памяти кушается (когда С++ жрет 16мб оперативки и 30% видеокарты)

вот видео для сравнения, обратите внимание на затенение конечных лучей(прозрачность) и сложение цветов в ярко белый, также освещение сцены делает линии более четкими