maksipes, вопрос на тостер - не ценится.
Если вы уже знаете ответ что идея ваша никому не нужна зачем спрашиваете? Надежда умирает последней и хочется услышать другое? :)
Если вопрос у вас о другом - о другом и спрашивайте.
Где искать ресурсы, как пилить проект без денег, как исследовать рынок, как тестировать прототип, на каких условиях привлекать людей и прочее - вот это все. Когда вы на самом деле решите что-то делать у вас правильные вопросы сами появятся.
Формально под это определение код автора вполне себе подходит, при условии что у него нет кода входа и выхода, но можно сказать что он ему и не нужен. А присваивание вполне себе атомарная операция и вполне себе меняет состояние.
Ostic, при чем тут остров пасхи, строки в JS и строки в html - совершенно разные строки. Перечитайте мой ответ еще раз, вы не поняли о чем я говорю. То что в html стоит utf-8 не имеет никакого значения. Там может быть что угодно. Из этого чего угодно браузер сформирует потом utf-16 строки в памяти если у вас будет что-то вроде
const x="люблю поспорить когда мне отвечают на мой вопрос"
вы указываете что-то другое, не строки JS из памяти?
Именно, вы пишете строку из латинских символов в кодировке заданной для данного html файла.
У вас там может опять же что угодно и совсем не в utf-8.
То что браузер будет делать с этой строкой и как он сформирует html-документ из того что есть в переменных в движке JS - это уже другой вопрос.
Пример который вы привели - вообще никаким боком к JS не относится, но предположим что там на самом деле кусок JS кода.
Владимир Проскурин, Ну это уже философский спор, так то есть люди которые утверждают что JS без классов это самый правильный ООП. Есть и те кто утверждает что даже Java не достаточно ООП.
К тому же автор говорит "бизнес логику вынести и использовать ООП" - ни слова что это будут классовые реакт-компоненты, я понял это так что него там будет как раз "правильное" ооп в бизнес-слое, с классами, наследованием и дальше по списку, а функциональщина - в компонентах.
Но как мне те же "one", "two", "ten", в разные столбцы в бд по ajax перенести? Например "ten" в столбец "test", "two" в "test2"
все проясняет, то это не так.
Это по смыслу звучит примерно как "я сижу на стуле, но что мне делать со сметаной?"
На встречный вопрос "что за стул, какая такая сметана?" вы отвечаете "вы помочь хотите или докопаться до вопроса?"
rom4shk4, вам и правда стоит сформулировать вопрос получше. Если конечно хотите помощи.
Ну или вы можете обижаться и дальше и удивляться почему люди не хотят "тратить на вас свое время".
Тимофей Федянин, Теория мало чем отличается от теории любой другой разработки продукта. Требования, задачи, решения, в зависимости от методологии разработки - налаживается разный процесс.
Чаще всего пилят исходя из требуемых фич - описывается что нужно, пилится. Описание фичи чаще всего или на словах или wireframe. Иногда бизнес сначала работает с дизайнерами и разработчикам приходит уже красивый макет, но не всегда.
Дизайн может быть до кода, может быть и после. Код обычно пишется сразу с правильной версткой, но бывает что делается примерно нужная структура и потом уже стилизуется когда функционал готов.
Все эти визуальные вопросы обычно хорошо помогает решить готовая библиотека компонентов.
Отдельный верстальщик для приложений не частая роскошь.
Для сайтов - отдельного верстальщик в команде встречается заметно чаще.
В целом, количество вариантов процессов и способов работы настолько разнообразно что единых "теории и подхода" нет. Все зависит от конкретной команды/компании, их привычек, опыта и т.п.
В самом детальном варианте это может выглядеть как-то так:
- Бизнес описывает фичу
- Дизайнер её рисует, показывает бизнесу и правят пока всех не устроит
- в сложных случаях на предыдущем шаге могут участвовать разработчики чтобы не понарисовали фантастику и вообще немного разбавить творческий полет мыслей суровой реальностью (не все что можно придумать - можно сделать и не все из того что можно сделать является оптимальным вариантом)
- задача приходит разработчикам, они ее реализуют попутно взаимодействуя с бизнесом где надо
- Когда функционал готов, верстальщики доводят это до совершенной красоты и соответствия макету
- задача уходит в QA.
- QA говорит что исправить, это правится пока всех не устроит.
- таск выезжает в релиз, бизнес смотрит и либо просит все переделать либо оставляет как есть
В реальности в любом месте какой-то этап может быть пропущен, либо они могут быть перемешаны как угодно.
stpnov, если "логически понять" то это к вам лично вопрос. Как угодно можно сделать.
Например если он хочет продлить не дожидаясь окончания - принимать оплату сейчас а реально давать/забирать слоты по окончанию текущей. Или давать прямо сразу больше слотов но со скидкой, так как подписка уже есть, ну и так далее, насколько фантазии хватит. Посмотрите как это сделано в других сервисах подписок, может какие-то идеи почерпнете.
stpnov, Сначала решите как это должно работать с точки зрения пользователя. что и когда ему доступно, как он должен за все это платить, и так далее. опишите ваш "тарифный план" для полльзователя.
А потом уже будете смотреть как это все хранить и организовать.
Сейчас такое ощущение что вы не знаете как оно должно все работать, и потому и каша, но это вопрос в первую очередь не технический.