Валентин: очень часто конечный автомат для своей прикладной задачи проще реализовать самому, чем использовать какую-то библиотеку. Конечный автомат - это просто "идея организации логики", а не какая-то особая библиотечная функциональность.
Boogie1989: не будет неправильным. Лишнее - это всё, кроме выбранного подмножества тегов. Обычно выбранное подмножество - это пара-пятёрка тегов типа и B и I. Решайте сами, какое форматирование вы хотите предоставлять пользователю.
Да, действительно, split проще, не нужно мудрить с регулярными выражениями. Единственное возможное преимущество моего варианта в том случае, если URL вводится руками и пользователь может опустить префикс "http://".
Можете прям тут озвучить бюджет и тех-задание. Можете воспользоваться фриланс-биржами. Можете обратиться в рекрутинговое агентство, чтобы получить программиста в штат. Не думаю, что вы спрашиваете всерьёз.
ng-if="current_user.subscriptions.some(subscription => subscription._id == season._id)" - только вместо _id воспользуйтесь полем, которое можно сравнить.
walkaway: видимо, я должен догадаться, что в объекте. Нет, не смог. Приведите примеры реальных данных, чтобы получился более предметный разговор, а не попытки телепатии.
Нет, "track by" должен работать и с переприсвоением массива. Перерисовка, возможно, происходит из-за другого кода.
---
If you are working with objects that have an identifier property, you should track by the identifier instead of the whole object. Should you reload your data later, ngRepeat will not have to rebuild the DOM elements for items it has already rendered, even if the JavaScript objects in the collection have been substituted for new ones.
До 9-ти игроков. Также в гугле можно набрать слова "poker calculator online", чтобы проверить все свои догадки относительно вероятностей в зависимости от количества участников и открытых карт на столе.
azverin: Использование различных пользовательских параметров для осуществления действий совершенно не соответствует идеологии REST (несмотря на всю её абстрактность у неё есть вполне конкретные практические предпосылки), чревато проблемами будущей поддержки и масштабирования. В урле должен быть адрес _ресурса_, а действие с ресурсом должно выражаться стандартным HTTP-глаголом по работе с ресурсом. Тогда и поведение браузера будет логичным (отличие GET от POST там не просто так), и коды ошибок можно использовать стандартные (которые тоже придуманы исходя из "ресурсной" терминологии/идеологии), и механизмы кеширования будут задействованы правильно (т.к. менять объекты могут только "избранные" глаголы, а урл строго соответствует ресурсу вне зависимости от осуществляемого действия), и документация API будет гораздо компактнее (т.к. не будет описывать новые логики относительно REST).
Если нужны нестандартные действия - вырази их в форме новых подчинённых ресурсов (например, представляя их "квитанциями об операции", в стиле документооборота), с которыми работают всё те же стандартные глаголы REST.
