С помощью props.navigation.state.routes [0] .routes.slice (-1) [0] .routeName я могу получить активный маршрутизатор, чтобы иметь возможность стилизовать. Если у вас есть лучший способ, я был бы рад прочитать.
Не совсем то, что я ожидал, но сейчас это работает хорошо:
export default (CustomDrawerContentComponent = props => {
const activeRouterName = props.navigation.state.routes[0].routes.slice(-1)[0].routeName
return (
props.navigation.closeDrawer()} style={styles.close}>
Luis Coimbra
Apaixonado por Jesus
{['Início', 'Perfil', 'Notificações', 'Criar Evento'].map(routerName => (
props.navigation.navigate(routerName)}
style={{
color:
routerName == activeRouterName
? color.secondary()
: color.dark.contrast,
margin: 16,
fontWeight: 'bold'
}}
>
{routerName}
))}
)
})
Результат:
Возможно, вам придется принять во внимание еще одну вещь: что, если вы хотите, чтобы пользователь / вы сами могли определять своих собственных слагов. Может быть, алгоритм не всегда достаточен.
Если это так, вам все равно нужно более или менее сохранить его в базе данных.
Если нет, я не думаю, что это имеет большое значение, вы можете сгенерировать их на лету, но если вы не уверены, хотите ли вы изменить их или нет, оставьте их в базе данных. На мой взгляд, нет никакой реальной проблемы с производительностью ни с одним из методов (если генерация на лету очень медленная или что-то в этом роде).
Выберите наиболее гибкий вариант.
Не будет ли смена слагов для существующих страниц действительно плохой идеей? Для начала это сломало бы все ваши ссылки.
Отредактируйте, следуя разъяснениям Гая в вопросе: Вам все еще нужно учитывать старых слизней. Например: если вы измените свой алгоритм slug, Google может начать видеть несколько версий каждой страницы, и вы можете подвергнуться штрафу за дублирование контента, или в лучшем случае в конечном итоге разделить PR и SERP между несколькими версиями одной страницы. Чтобы избежать этого, вам понадобится каноническая версия страницы, на которую перенаправляются все неканонические слагы - и, следовательно, вам все равно понадобится канонический слаг в базе данных.
Для генерации слизняков я не думаю, что время генерации должно быть проблемой, если ваш алгоритм слизняков не слишком сложен! Точно так же, место для хранения не будет проблемой.
Я бы сохранил слаг в базе данных по той простой причине, что слизни обычно образуют часть постоянной ссылки, и как только постоянная ссылка отсутствует, она должна считаться неизменной. Возможность менять слаг для опубликованных данных кажется плохой идеей.