Welcome to the TinyMCE Cloud demo!
Please try out the features provided in this full featured example (excluding Premium Plugins ).
Got questions or need help?
- Our documentation is a great resource for learning how to configure TinyMCE.
- Have a specific question? Try the
tinymcetag at Stack Overflow. - We also offer enterprise grade support as part of TinyMCE premium plans.
A simple table to play with
| Product | Cost | Really? |
|---|---|---|
| TinyMCE Cloud | Get started for free | YES! |
| Plupload | Free | YES! |
Found a bug?
If you think you have found a bug please create an issue on the GitHub repo to report it to the developers.
Finally ...
Don't forget to check out our other product Plupload, your ultimate upload solution featuring HTML5 upload support.
Thanks for supporting TinyMCE! We hope it helps you and your users create great content.
All the best from the TinyMCE team.
При этом практически все фичи бизнес-логики будут изолированными.
Самое важное, что FSD даёт, — это низкая связанность и одновременно высокая сцепляемость (low coupling, high cohesion). Это значит, что модули почти ничего не знают друг о друге и не зависят друг от друга, при этом получается единая, логически связанная сущность.
FSD лучше всего подходит для больших проектов, где постоянно меняются требования к бизнес-логике приложения. При этом у неё довольно высокий порог вхождения: новичкам бывает сложно разобраться в сути методологии.
Наконец, нужно закладывать дополнительное время на проектирование, то есть из-за FSD растёт time to market. Чтобы этого избежать, можно использовать упрощённую версию методологии.
О чём спросить самого себя, чтобы выбрать подходящую методологию или архитектурный подход
На самом деле FSD — это не архитектура. Сам по себе фронтенд — это слой представления, его задача корректно отобразить данные. Вся логика его работы в любом случае хранятся на бэкенде, поэтому любая «архитектура фронтенда» в действительности является методологией. Правда, это не касается больших сервисов, таких как Figma, у которых действительно сложная бизнес-логика или функции работы с офлайновыми базами данных могут храниться на клиентской стороне.
Но фронтенд в приложениях с годами становится всё больше: в нём постепенно появляется своя бизнес-логика, множество разных состояний, работа с данными, офлайн базами данных. Поэтому разработчикам полезно понимать разные архитектурные подходы: layered, event driven, FSD и другие, — уметь с ними работать и применять даже в проектировании фронта.
Выбирая подход к разработке фронтенда, стоит задать себе четыре вопроса:
- Что должна делать система?
- Как она должна себя вести?
- Какие у неё есть ограничения?
- Какие фичи важны, а от каких можно отказаться?
Ответив на них, вы, скорее всего, уже поймёте, что нужно использовать FSD, модульную или какую-то другую методологию. А ещё может оказаться, что клиентская часть очень простая и для разработки вообще не нужен архитектурный подход.
Ответы на эти вопросы помогут ещё до старта проектирования понять, как будут взаимодействовать разные элементы приложения, какие у него функциональные и нефункциональные требования. Всё это в любом случае улучшит качество проекта, облегчит его разработку и поддержку.
Другие интересные мысли Сергея и примеры проектирования фронтенда по методологии FSD смотрите в записи выступления.