Создать удобную документацию

[zerkalica]

• Продумать иерархию документации
• На сайте mol.js.org добавить раздел
• Примеры и демки упрятать в раздел
• Добавить систему тегов и выстроить по ней иерархию

[nin-jin]

Звучит как эпик.

[Alexufo]

а зачем теги? Их всегда или забывают ставить, или ставить корректно, или называют так, что кроме одной сущности ничего не подцепишь. Тем более в документации. Теги подразумевают что документация ад.

[zerkalica]

Вопрос можно поставить так.: можно ли сделать модульную документацию удобочитаемой и полезной? Например, собирать меню по тегам. Или ручками все правки?

[nin-jin]

Теги нужны для нечёткого поиска. Например, пользователь ищет "dropdown" - надо показать $mol_pop, $mol_select, $mol_search.

[timeshift92]

предлагаю сделать туториал как у свелт (https://svelte.dev/tutorial/basics), объясняя каждый аспект, потому что это база, надо хотябы основу сделать более подробно

[gituser3000]

Нужен маппинг от концепций популярных фреймворков в концепции $mol. Реакта/ангуляра достаточно.
Как пример:

1. Динамическое скрытие/показ по условию (*ngIf)
2. Рендеринг списков (*ngFor)
3. Input/Output/пропсы
4. Подписки на события
5. Хуки жизненного цикла??
6. Http
7. Роутинг
8. Стейт менеджмент/сервисы
   Отдельно стоит пройтись по синтаксису tree с понятными примерами на тему ЧТО и ЗАЧЕМ.
   Например event *
   ^
   Имеет смысл использовать только для наследуемых компонентов, а не для любых...

Туториал аля свелте это неплохо, но без интеллисенса в tree это дохлый номер. А чтобы завести его туда, надо завести его хотя бы во фреймворк..)

[zerkalica]

Описание методом аналогий отберет много ресурсов и не поможет тем, кто плохо знает попсовые фронтенд-фреймворки (к примеру, бэки, которые хотят быстро во фронт из коробки). Некоторые вещи, в mol в принципе отсутствуют и не нужны, как хуки.

Полезнее формулировать задачи в бизнес-терминах, как сделать то-то. Лучше вот такой список задач и сформулировать.

[Alexufo]

@zerkalica я не совсем соглашусь. Не ссылаться на аналогии или концепции попсовых фреймворков - отрезать эту аудиторию, и заклеймиться самыми умными, не считающими нужным снизайти до земного мира. Какие-то связи нужны - это уважение к другому опыту.
Первым делом я нырну туда, где мне покажут аналогии с текущим опытом чтобы обьяснить различия и новые концепции.

[PavelZubkov]

В доках можно показать упрощеную реализацию основных модулей(atom, view, еще что-то?) и написать на них какую-нибудь тудушку

[nin-jin]

Я думаю должен быть кукбук как для новичков во фронтенде, так и для имеющих некоторых бэкграунд. Можно сделать как в каком-нибудь Dragon Age Origins, где у каждого персонажа приключение начинается со своей локации и своими стартовыми квестами, но ко второй главе все эти линии сливаются в один основной квест. То есть можно на старте дать людям возможность выбрать свой бэкграунд типа "я реактовод", "я джейкуерист" или "я вообще бэк". Далее каждому из них подаётся базис для выравнивания понятий с учётом их бэкграунда. А потом уже общая для всех часть как зная базис делать разные штуки.

[Alexufo]

Я считаю ошибкой использование не уникального графического контента. Это говорит о том что продукт не самодостаточен. Лучше вообще не привлекать графику в этом случае, чем заимствовать даже со свободной лицензией. А с кукбуком и схемой согласен.

[nin-jin]

О какой графике идёт речь?

[Alexufo]

из Dragon Age Origins? :-)

[timeshift92]

Круто, запилим игру:) кстати я видел такую игру только для ассемблера

[PavelZubkov]

Для Git вроде тоже есть какая-то игра, мб не одна

[Lyumih]

Дополню по улучшеню базовой документации:
#511
#512