Size: a a a

DocOps-сообщество

2019 March 05

NV

Nick Volynkin in DocOps-сообщество
sidigi
Для быстрой генерации документации очень даже неплох. Там поддержка vue компонентов, но заполнять это может только продвинутй пользователь или разработчик. Вообще vuepress мне понравился больше всег генераторов, при желании можно сделать и разделение на права и доступы, для этого можно воспользоваться oauth2.0  То есть документацию можно разделить (но это надо допиливать напильником)

VuePress больше подходит для того для чего он создавался - для документации отдельного продукта. Для совокупной базы знаний он слабоват - там есть теги поиска, но нет полнотекстового поиска например
Кстати, про права доступа-то я пропустил. Вот это киллер-фича.
источник

s

sidigi in DocOps-сообщество
не только по заголовкам, можно в маркдаун добавить мета данные, будет искать и по ключевым словам
источник

A

Antonio in DocOps-сообщество
sidigi
не только по заголовкам, можно в маркдаун добавить мета данные, будет искать и по ключевым словам
Через front matter?
источник

s

sidigi in DocOps-сообщество
Nick Volynkin
Кстати, про права доступа-то я пропустил. Вот это киллер-фича.
Ну это мы костыль свой пили, просто авторизация через свой наш сервис авторизации, там выдаются права доступа, а дальше vuepress типа проверяет что показывать а что нет. Но это пока реализовано очень грубо и костыльно будем переделывать на фронтенд авторизацию и jwt токены
источник

s

sidigi in DocOps-сообщество
Antonio
Через front matter?
Ага
источник

s

sidigi in DocOps-сообщество
Перед показом страниц, можно вставить любой скрипт, в том числе и скрипт проверяющий у пользователя кто он такой и что ему показать в зависимости от роли
источник

ML

Maksim Lapshin in DocOps-сообщество
Нац Нац
Погибаю на винде без длинного тире, поставил бы пакет, чтоб его юзать. А тут какие-то штуки надо ставить чтобы жмакнуть тире
— — — —

вот, можешь копипастить
источник

A

Antonio in DocOps-сообщество
Nick Volynkin
Как это по-фронтендерски! Следующий шаг — добавлять зависимости проекта прямо в маркдауне. Например, нужно нам многоточие поставить. Не искать же символ юникода, в самом деле. Лучше подключить библиотеку, в которой есть многоточие. :)))
Иногда убогость и простота маркдауна играет с тобой же злую шутку. Как по мне, возможность исполнять код внутри маркдауна примерно то же, что использовать любой markdown flavor, который расширяет его базовую спецификацию, тот же gfm.
источник

s

sidigi in DocOps-сообщество
import {Auth} from './auth';

export default ({
   Vue, // the version of Vue being used in the VuePress app
   options, // the options for the root Vue instance
   router, // the router instance for the app
   siteData, // site metadata
}) => {
   let auth = new Auth({
       'admin': {
           'allow': '*'
       },
       'cfo': {
           'allow': '*'
       },
       'account': {
           'allow': '*'
       },
       'head': {
           'allow': [
               '/main',
               '/employees',
               '/users'
           ]
       },
       'user': {
           'allow': [
               '/main'
           ]
       },
       'content': {
           'allow': [
               '/main',
               '/content'
           ]
       }
   });

   router.beforeEach((to, from, next) => {
       if (! auth.canSee(to.path) && from.path !== '/'){
           location.href = location.origin + '/auth';
       }

       next();
   });
}

костыль примерно такого характера
источник

A

Antonio in DocOps-сообщество
@sidigi_coder я сейчас люто упёрся во front matter: у нас используются кастомные переменные, в которых хранятся длинные названия и ссылки на эндроинты, чтобы не повторять их по миллион раз в доке.
Не могу понять, как их прописать в конфиге vuepress
источник

s

sidigi in DocOps-сообщество
enhanceApp.js - тут можно добавить практически всё что угодно)
источник

s

sidigi in DocOps-сообщество
Если бы я был фронтендером я бы уже накрутил делов)))
источник

A

Antonio in DocOps-сообщество
@sidigi_coder Там вроде как через сам конфиг это можно сделать
https://jekyllrb.com/docs/configuration/front-matter-defaults/
источник

A

Antonio in DocOps-сообщество
sidigi
Если бы я был фронтендером я бы уже накрутил делов)))
аналогично)
источник

s

sidigi in DocOps-сообщество
я бы хотел через front matter добавить role пользователя и в зависимости от этой роли чтобы эта часть контента была разрешена к показу или запрещена, в том числе и в навбаре и меню, но к сожалению система распределённая и это надо делать на этапе сборок или показов, возможно я ошибаюсь, но когда я такое пытался реализовать - не смог
источник

НН

Нац Нац in DocOps-сообщество
sidigi
я бы хотел через front matter добавить role пользователя и в зависимости от этой роли чтобы эта часть контента была разрешена к показу или запрещена, в том числе и в навбаре и меню, но к сожалению система распределённая и это надо делать на этапе сборок или показов, возможно я ошибаюсь, но когда я такое пытался реализовать - не смог
Когда найдете такую штуку удобную - зовите, надо
источник

s

sidigi in DocOps-сообщество
и даже чтобы можно было делать так

\\\```roles(admin|cfo)
//// какой то контент```
источник

NV

Nick Volynkin in DocOps-сообщество
sidigi
я бы хотел через front matter добавить role пользователя и в зависимости от этой роли чтобы эта часть контента была разрешена к показу или запрещена, в том числе и в навбаре и меню, но к сожалению система распределённая и это надо делать на этапе сборок или показов, возможно я ошибаюсь, но когда я такое пытался реализовать - не смог
Получится на уровне документа, а можно же хотеть ещё и внутри документа блоки выключать.
источник

NV

Nick Volynkin in DocOps-сообщество
sidigi
и даже чтобы можно было делать так

\\\```roles(admin|cfo)
//// какой то контент```
вот да, так.
источник

НН

Нац Нац in DocOps-сообщество
Nick Volynkin
Получится на уровне документа, а можно же хотеть ещё и внутри документа блоки выключать.
Так хоть что-то не-кастомное умеет?
источник