В таком случае нужно 2.1 или даже 2.2 ждать, поскольку в 2.0 далеко не все запланированные нововведения выйдут. В частности, там не будет routable components, которые являются одним из ключевых изменений концепции.
@Aingis нет, я просто добавлю для него другой класс: block--removable-big. Ведь именно этому нас учит БЭМ, правда? Я еще раз повторю, что пример не претендует на использование в продакшн. С помощью него я лишь хотел показать, что important можно и нужно использовать там, где он семантически необходим. И ни в коем случае не для перекрывания других правил.
P.S. Если отрывать руки всем, кто умеет пользоваться доступными инструментами, работать будет некому.
@Petroveg Мы с Вами говорим об одном и том же. Я как раз и попытался привести пример обоснованного использования important. Пример абсолютно синтетический, придуманный на ходу. Будет очень здорово, если Вы приведете лучший пример. Это будет полезно для всех.
@zBit, ну, Express - это веб сервер, а не фреймворк для построения REST API. Restify тоже достаточно низкоуровневый. Большой API, мне кажется, на нем будет поддерживать достаточно сложно. На мой взгляд, лучшая платформа для построения RESTful API на данный момент - RoR. Sails.js наиболее близок к нему по идеологии. Но это лично мое мнение. Вот еще, кстати, статья на хабре есть по теме: habrahabr.ru/post/222259
Поставьте breakpoint в fnFooterCallback и посмотрите, почему в iTotal и iTotal2 появляются нецифровые значения. NaN возникает из-за того, что parseInt не может найти в строке цифровую часть.
@ndsdmfwg У gmail есть оффлайн приложение. К тому же, и с gmail, и с яндексом можно использовать pop3/imap клиенты. То есть Ваша почта будет всегда при Вас. А если отвалился интернет, то на внутренний почтовик почта все равно не придет, так что тут они равноценны.
Да, именно так. На больших приложениях еще может быть небольшая разница в производительности, поскольку C# компилируется в MSIL, а JS - интерпретируется.
Рекурсивная установка таймаута - не самое лучшее решение. Я бы сделал через setInterval/clearInterval. Хотя, полагаю, тут имеет место логическая ошибка, поскольку код не выполняет нужных действий с первого раза.
Я бы ввел статус заявки (если такого еще нет) и по SSE отправлял событие изменения статуса заявки. А фронтенд, в зависимости от нового статуса, так или иначе обрабатывает контент. Это позволит более гибко управлять отображением. К примеру (статус - действие), created - добавляем заявку, canceled - удаляем заявку с сообщением об отмене заявки пользователем, started - удаляем заявку с сообщением о начале игры. Ну или как-то по-другому, в зависимости от жизненного цикла заявки.
