-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Discussion: TextLink
component
#2947
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
Comments
There can be multiple combinations of this possible but, So the code will look like either : But if Community don't want this idea... I think the code should be : What do you think? @lindapaiste @raclim and others |
|
Yes indeed, this is a great idea! Introducing a centralized TextLink component will not only enhance the visibility of clickable links but also contribute to a cleaner and more maintainable codebase. I'm want to actively contribute on implementing this TextLink component. If you have any further suggestions or considerations, feel free to share them! |
Hi @lindapaiste, I believe the best approach for this is to utilize the Recoil library. With this library, we can define all the props in a separate file along with the functionalities they will perform. Afterwards, we can simply use the functions provided by this library and utilize whichever prop we need throughout the entire application. The main advantage of this library is that it will save us from prop drilling and the re-renders that often occur. It achieves this by allowing any component to subscribe only to the specific props they actually need without worrying about parent and child components , and without necessitating the passing of props from parent to child. This not only reduces unnecessary re-renders but also makes our code much cleaner and easier to manage I'd be happy to work on this issue. You could assign it to me, and I can get started. |
I’m familiar with Recoil and I think it’s pretty cool. We’re deeply entwined with using Redux as our state management system so I don’t have any plans to change that. Also I don’t see how Recoil relates to this issue at all. I think you might be misunderstanding the discussion. The idea is that there are certain props of a |
Hi @lindapaiste my plan was not to change the state management library I understood the issue very well , my goal was to have recoil library only to control the css of these links and use them wherever we want instead of creating a component for these , but if you want a component for them I am up for that as well. |
Responding to #2940 (comment) - I want to centralize the discussion here.
I think it's important that we follow these best-practices. Honestly I love rules because it removes a lot of subjectivity and helps me make decisions. So I've been reading a bit. The standard is that when a link is presented inline with other text it should have an underline, regardless of color. That will make it so that links are obvious and fix most of the current issues. The underline is not necessary when we have an entire element that's a link. It's also acceptable to use bold instead of underline but IMO underline is more easily understood as a link.
The contrast ratio is close enough to passable that maybe we just need a slightly darker variation of the pink to use as a text link color for light mode? At least, it's very close to meeting the AA-level guideline. We have a ratio of 4.2 with |
@lindapaiste Thanks for looking into this! I'm down with using the underline as well over bold. I think the editor has a lot more standalone links (like in the About Modal) than inline ones. Maybe for those types of links the underline could show up on hover? I guess I was feeling a little hesitant about implementing color changes that might stray from p5.js' identity, but the 4.5 As an added note, I think looking at school/university websites would also be great for more references/examples because I think they've been required to meet these standards and are probably already implementing a lot of these (for example, NYU had an initiative to be AA compliant back in 2017). |
Tasks
TextLink
component based on how we want to customize the style for specific use-casesTextLink
componentTextLink
Increasing Access
We want to keep the codebase clean and keep the design consistent.
Feature enhancement details
We have had many issue recently relating to the visibility of text links throughout the app. I would like to centralize the discussion here.
The recurring problem is that it's not clear to the user that a certain text is a clickable link. We can improve this by changing the default style of the link as well as adding hover styles to make it look more interactive.
I don't want us to add lots of specific CSS to specific component because this is difficult to maintain. I think this is a good opportunity for us to expand our library of reusable core UI components with a
TextLink
. We might not want to have the exact same styles everywhere, so we'll want to have some props which can control styles.The goal of this issue is to discuss our API for the
TextLink
component and finalize what props we want.Depending on the API that we choose, the code might look like any of these:
^ This last one uses
boolean
props and is concise but probably more confusing.Ideas for props:
underline
with values"always"
,"hover"
,"none"
(what MUI uses)color
with values"always"
,"hover"
,"none"
to apply the theme primary accent color (pink or yellow)color
with values"primary"
,"inherit"
, etc. to choose from multiple theme colors (what MUI uses)primary
as aboolean
flag to make it pink (this wouldn't allow for pink-on-hover behavior)bold
with values"always"
,"hover"
,"none"
("hover"` shouldn't be used here, but keeps it consistent)bold
as aboolean
flagfontWeight
with values"bold"
or"inherit"
display
with values"inline"
(default) and"block"
Specific related issues:
References / how others handle this:
The text was updated successfully, but these errors were encountered: