Любой может улучшить или добавить фичу,, или исправить баг.
Для начала надо хоть бы одну штучку, малюсенькую, решиться и сделать.
А не выдумывать проблемы.
Это адекватный фреймворк. Ключевое слово фреймворк. Это не цмс.
router.push.setParam('page', '1');router.push.setParam('page', null); // и параметр уберетсяrouter.push.setParam('page', router.onlyInternal); // это значит, что под капотом добавить параметр, но в адресную строку не добавлять. Полезно для тех же прелоадеров, чтобы в несколько этапов грузить данные и состояние (этап) хранилось под капотом, но не в адресной строке браузераrouter.push.go(url);а) Это не javascript
б) Многих вещей пока не хватает. Но платформа активно развивается.
создай свою библиотеку компонентов и методов и преноси ее из проекта в проект через npm i.
В целом ты описал работу некой cms, а не фреймворка
А все что ты описал, это сугубо твои хотелки
И то только если много пользователей сайта/ЦА на нём сидит.
но не обязательно в автоматизированном.
адекватное времяя бы не сказал, что Cypress работает быстро.
{ log: false } везде где можно, и опа, уже 10-20 сек. А логов этих там всего-то штук 300. Ну куда это годится?Ну или устанет и наделает ошибок
Я уже часть реализовал. Но да, на это уходит время. Может быть, на реализацию всех требований им потребовалось бы несколько недель. И что, у них нет нескольких недель?
Или настоящие фанатики своего дела. Которые понимают, что работать - это сложно и вредно для здоровья, но их это не останавливает...
Ну, я уже реализовал часть этих фич. И код Next вроде уже немало покопал. Поэтому вряд ли я могу совсем "не понимать, как оно внутри".
3. Мне нужно сделать простенький кеш данных. Кеш нужно сделать именно в памяти, а не в БД и даже не в in-memory БД (я не против БД, но это требование заказчика). Поэтому приходится использовать обычную глобальную переменную. При этом и дергать, и записывать кеш приходится как в SSR (там эти данные потом идут в пропсы страницы), так и в API-роутах. И все бы хорошо, но вот почему-то оказывается, что глобальная переменная в SSR и глобальная переменная в API-роутах - это две разные глобальные переменные. Хотя по логике все сделано верно: глобальная переменная вынесена в модуль, который и импортируется там и там. Но вот так оно работает. И отсюда вытекает соответствующее поведение кеша. Зачем они так сделали? И API-роуты, и SSR находятся в Next, все это крутится в одном приложении, в одном процессе node.js, на одном порту... И вдруг вот такое поведение. С таким же успехом они могли вообще не делать API-роуты, я мог бы сделать API в виде отдельного микросервиса на Express.
Еще из-за этой проблемы, похоже, они сломали стороннюю либу - next-session.
Либа, конечно, имеет аналоги, но она была неплоха именно тем, что хранила данные не в самой куке, а в памяти сервера (и поэтому могла хранить весьма много данных, не раздувая при этом запросы и ответы). Ну а теперь в памяти сервера ничего хранить не получится.
Как видите - проблема не только у меня, но, очевидно, и у автора либы и других ее пользователей.
5. Недолго? Вы это решали в случае с Next? Почему в этом вопросе куча бравых ответчиков, но как пытаешься понять, с каким фреймворком для SSR знаком каждый из них, то натыкаешься практически на полный пшик?
Если решали, то поделитесь решением, пожалуйста.
Я бы сказал, что полноценные прелоадеры (которые появляются там, где надо, а не на всю страницу) - это весьма и весьма сложно.