Мне нужны несколько Go-разработчиков, чтобы проверить, не придумал ли я удобство там, где его нет
Недавно я писал здесь о GoFrame — экспериментальном веб-фреймворке, в котором интерфейс, компоненты и большая часть прикладной логики пишутся на Go.
С тех пор проект заметно изменился, но сейчас я уперся не столько в очередной баг, сколько в довольно неприятный для автора вопрос:
может ли человек, который не проектировал GoFrame, самостоятельно собрать нужный сценарий из уже существующих API?
Речь идет о небольшой странице, где адрес определяет загружаемые данные. Пока новый ответ готовится, предыдущий успешный экран должен оставаться на месте. Медленный старый запрос не должен перезаписать более свежий результат. Также должны нормально работать ошибка, повторная попытка, переходы назад и вперед и уход со страницы во время загрузки.
Собственную реализацию я уже написал, поэтому чужой код мне нужен не ради готовой фичи. Наоборот, важно понять, насколько очевиден путь к решению для человека, который видит API впервые:
-
где пришлось долго разбираться;
-
какие части API оказались полезными;
-
где пришлось вручную координировать состояние;
-
возникло ли ощущение, что фреймворку действительно не хватает отдельной абстракции.
Разбираться во внутренностях компилятора, GOX или WebAssembly не требуется. Достаточно обычного опыта с Go и готовности запустить существующий пример в браузере. В issue есть закрепленная версия репозитория, команды запуска, ограничения, проверяемые сценарии и шаблон короткого отчета.
Менять сам фреймворк не нужно. PR в основной репозиторий тоже не требуется — подойдет ссылка на ветку, commit или patch.
Незавершенная попытка тоже полезна. Если в какой-то момент задача покажется слишком запутанной или плохо выражаемой через текущие API, это полноценный результат, а не провал. ИИ или помощь другого разработчика использовать можно, нужно только честно указать это в отчете.
Сразу уточню: это не заказ и не конкурс, а добровольная исследовательская проверка. Мне нужно несколько независимых попыток, чтобы не принимать архитектурное решение только на основании собственного опыта автора.
Задача и все подробности:
https://github.com/graybuton/goframe/issues/117
Если решите попробовать, можно просто написать об этом в комментариях к issue. Буду благодарен и за завершенное решение, и за честное описание того, на каком месте все стало неудобно.