-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scope libraries depending on turbolinks version #75
Conversation
Nice work!! A great first pass IMO |
I've given this some thought. Your solution is clean and makes things simpler to manage on the back end, but for visitors to the site, it could be confusing. A visitor to the site looking for the Twitter solution might scan the menu and just click the first Twitter link they see, not realizing there's another one further down. Other than the menu (which is subtle and can be missed), there is no indication on the page of which version of Turbolinks the solution is for. Given that each solution page is made up of two parts (the official implementation and the solution), and that the official implementation is going to be the same regardless of what version of Turbolinks the solution is for, perhaps the better way to go about this is to just include solutions for both versions on the same page and label them accordingly. This way, there won't be any confusion for the end user. What do you think? As a side note, instead of using "Turbolinks 3" and "Turbolinks 5" as the identifiers, you should use "Turbolinks Classic" and "Turbolinks". Although if you wanted to add a "5" to the second one for clarity, I probably won't fight you on it. |
Ok, make sense 👍 I guess an anchor menu (wiki style) would be welcome as well. Or even tabbed content. One question though: which one should be first? you could say «classic» be it might be more used. But I'd say the new solution since they are the new hot stuff. What do you think? |
Nice work! Thanks for getting this done @borisrorsvort
|
@reed did you had a chance to check? |
Your changes look good, except for the structure of the solutions. Since the official implementation is going to be the same no matter the version of turbolinks, I was thinking the structure of the solutions should avoid repetition and look more like this:
It doesn't really matter to me which solution is first. Thoughts? |
As we talked about, here is a wip scoping of new solutions for turbolink 5.
I was not familiar with nanoc so please comment on architectural choice and naming.
This is attempting to answer #72 issue