useremo conn.path_info
che restituisce il percorso attuale, come una lista di stringhe invece di conn.request_path
. Potremmo usarlo per ottenere il nostro aiutante active_class
.
def active_class(conn, path) do
current_path = Path.join(["/" | conn.path_info])
if path == current_path do
"active"
else
nil
end
end
Poi lo usano come:
<%= link "Users", to: user_path(@conn, :index), class: active_class(@conn, user_path(@conn, :index))%>
noti che user_path/2
due volte sopra. Potremmo a secco che con un altro aiutante:
def active_link(conn, path, opts) do
class = [opts[:class], active_class(conn, path)]
|> Enum.filter(& &1)
|> Enum.join(" ")
opts = opts
|> Keyword.put(:class, class)
|> Keyword.put(:to, path)
link text, opts
end
Perché utilizzare conn.path_info
invece di conn.request_path
? Questo perché conn.request_path
restituirà il percorso esatto richiesto dall'utente. Se l'utente visita il percorso /foo/
, quindi conn.request_path
restituirà /foo/
. Il problema è che l'helper del router che confronteremo restituirà sempre un percorso /foo
senza il trailing /
.
Spero che questo aiuti! Fammi sapere se qualcosa non è chiaro.
Questa sembra una buona scelta per l'integrazione nel sistema Controller. Alcuni problemi con il tuo codice di esempio. 'defmodule LinkHelper do' e' importa LinkHelper' – rockerBOO
@rockerBOO buon punto - deve aver dimenticato di aggiornare l'importazione quando l'ho copiato! – Gazler
Questo approccio non imposta un collegamento a "attivo" per tutte le azioni del controller che si passa ad esso? Ad esempio, 'page_path (@conn,: index)' e 'page_path (@conn,: show)' saranno entrambi impostati su attivo se si passa 'PageController' a' active_link/3'. Non vogliamo che la pagina di presentazione sia "attiva" solo se siamo in page.show? – Gjaldon