Было обнаружено, что если автор поста-черновика (или человек, зашедший по прямой ссылке) оставит там комментарий, то этот комментарий покажется в новостях подписчиков. Пофиксили.
Записи в черновиках не отображаются в вашем блоге, ленте и поиске. Но по прямой ссылке они доступны. Таким образом, у вас остается возможность показать кому-то запиcь до публикации.
Было бы хорошо, если при нажатии на кнопку Удалить запись в блоге (крестик вроде), у меня система все-таки спрашивала, что-то вроде этого "Вы действительно хотите удалить эту запись", и после подтверждения только удалять.
Добрый день! Глюк в следующем, что когда нажимаешь "Мне нравится", а потом нажимаешь рассказать друзьям, то ссылка не на то что ты хочешь рассказать, а на совсем другое. http://gyazo.com/70242b5e844a8aabae1371bbdd887bad
Ребята поправьте, пожалуйста, работу с History API. Глючит адски. При медленных ответах от сервера поведение страницы предугадать вообще невозможно. Отсюда все эти дубликаты постов + неведомое самостоятельное переключение страниц. Да и back-end судя по всему очень стоит пересмотреть если у вас сейчас такие ответы местами до 5-7 (!!!) секунд, то что будет когда ваша текущая статистика увеличится вдвое?
Уточните суть найденных вами ошибок. Что именно глючит в history, где появляются дубликаты постов и какая страница открывается 5 секунд?
У нас долгие разве что страницы с граффиками статистики, но эта проблема решится в обозримом будущем. Остальные должны открываться моментально, поэтому важно знать, где именно вы столкнулись с таким ожиданием.
History API: механика - пользователь нажимает ссылку, на сервер уходит запрос. Когда приходит ответ происходит обновление части (или всей) страницы. Все хорошо ровно до тех пор пока по каким-то причинам (вам виднее по каким) ответ от сервера начинает задерживаться.
Ситуация: Нахожусь на странице поста какого-нибудь блога. Нажимаю на ссылку-логотип спарка (ведет на главную страницу). Визуально ничего не происходит. Но технически в этот момент уходит запрос на сервер. Ничего не происходит потому что ответ еще не пришел. Я решаю нажать на другую ссылку. Например лента новостей. От нее запрос возвращается быстрее и я попадаю на страницу ленты. Но после перехода на ленту приходит ответ на первый запрос и лента превращается в главную страницу спарка. Для обывателя это должно выглядеть как неведомая ху..ня и не пишут вам об этом сюда скорее всего лишь потому, что просто, по не знанию, не связывают такие штуки с работой сайта.
О комментариях. Ситуация (судя по наблюдениям нередкая): Нажимаю ответить. Набираю комментарий. Нажимаю отправить. Ничего не происходит. Но (опять же как мы уже знаем) запрос уже пошел на сервер. Нажимаю отправить снова. Приходит ответ от сервера (на первый запрос или на второй не суть) и появляется комментарий. Ответы могут прийти почти одновременно и, соответственно, два комментария появятся одновременно. Такую картину, я уверен, вы и сами уже наблюдали не раз.
Избавить от этой ситуации вас могло либо использование mvc фреймворка либо, как минимум, на стороне фронт-энда предусматривать задержку от сервера и вешать на кнопки отправки данных аттрибуты состояний. Например если клик был сделан, то залочить кнопку чтобы юзер тыркая по ней несколько раз не производил лишних запросов.
Тикет об уведомлениях (здесь немного ниже). Насколько я понял это не баг, а просто обычный недосмотр. Решается тоже несложно добавлением 1-2 условий. Например выводить уведомления о блогах и комментариях которые "моложе" даты подписки на проект или ветку обсуждений.
О back-end. Просто заметка и вам решать как поступить. Можете проигнорировать и послать меня в задницу :)
Открываем страницу темы недели http://spark.ru/weekly/hunting
Видим прелоадер перед появлением списка комментариев. Открывая первый раз эту страницу я допускаю, что это нормально. Но второй, третий и каждый раз прелоадер. Делаю вывод что запрос на выборку списка комментариев происходит при каждом запросе. Или же у вас адски медленный кэш ;) .. или его вообще нет. Но тогда стоит задуматься. Если сейчас прелоадер висит доли секунд (что уже заметно), то представим сколько на него будет смотреть юзер если комментариев будет не 60, а 300.
Про повторные нажатия на Отправить в вопросах согласен. Это была ошибка конкретно этого раздела.
Тикет об уведомлениях видели и знаем. Это не баг, в данный момент такая реализация в рамках первой версии фида. Улучшения выборки появятся уже в ближайшее время. Помимо этого, часть операций будет вынесена в оперативную память, что еще сильнее ускорит работу. Вам понравится.
Комментарии на сайте встраиваются после загрузки самой страницы. Прелоадер намеренно появляется на небольшое время. Общее поведение сейчас такое, как и задумано, за исключением того, что в будущем функционал этого раздела будет наращиваться. Не понял, в чем суть абузы, в том что доли секунды виден лоадер? Разницы между 60 и 300 записями нет.
"Разницы между 60 и 300 записями нет" сейчас звучит довольно спорно.
Чтобы не вступать в полемику стоит сравнить две любые записи в блогах. Ту у которой 4-5 комментариев и ту у которой их около 20. Плюс, опять же, это лишь заметка и общий посыл запроса был не в укор технологиям, а намек на слабые стороны в user experience.