bufferapp / buffer-components Goto Github PK

Hello maintainers,

I have been working with the codebase and noticed that the API documentation for the components is currently generated using PropTypes. While PropTypes has served us well, I believe we can enhance the developer experience and potentially catch type errors more efficiently by migrating to TypeScript.

Here are a few benefits that we can obtain from this migration:

1. Stronger Type Checking - TypeScript offers a robust type-checking system which can help catch type errors during development rather than runtime, promoting code reliability.
2. Improved Developer Experience - Leveraging TypeScript can enhance auto-completion, and type checking features in various IDEs, which can be a boon for developers.
3. Better Documentation - With TypeScript, we can utilize tools like TypeDoc to generate detailed API documentation automatically, improving the ease of use for end developers.

I understand that this migration can be a significant change. However, I am more than willing to allocate some of my weekends to initiate this process and perhaps carry out the migration incrementally to lessen the burden on the team. Before proceeding, I'd like to hear your thoughts on this and whether you see potential value in transitioning to TypeScript.

Thank you for considering this enhancement, and I look forward to hearing from you.

Heya team,

Colin noticed something odd with 12 hour time with the hour range. It goes from 12 -> 11. This feels a bit odd.

If you look at other parts of the app, we use 1->12 regardless of AM or PM.

I'm curious if we could make this change? It feels a bit more intuitive and makes things consistent too.

I looked into getting this fix in there, but got a bit stumped on the genArray function in InputTime to get this to work. Any ideas on how how to get this working and not create any breaking changes for the DateTimeForm (in buffer-web-components)?

cc @hharnisc & @stevemdixon

Hey there!

Wondering if we could change the default prop for the alt property in the Image component to be an empty string instead of "Image"? The best practice here would to leave an empty alt text as alt="image" would create a bit of redundancy in the screen reader! :) It would read: "image image" in this case!

More about funky alt text edge cases here: http://webaim.org/techniques/alttext/

Happy to make a PR for this one, but wanted to make an issue first!

marginRight is applied to each select element within InputTime. This feels smooth for the 12-hour state as the AM/PM select doesn't have marginRight. I'm curious if we can apply this same behavior to the 24-hour state as we're seeing a slight misalignment when centering InputTime.

With marginRight on minutes:

Without marginRight on minutes:

When setting the noStyle prop on a Button component that contains no text, the child is no longer vertically centered. This is apparent when setting an Icon component as the child.

Screenshot:

How to replicate
See the ScheduleTable component in buffer-web-components.

Heya @hharnisc @alvarezmelissa87 @stevemdixon!

Just a heads up on an axe-core error I'm seeing while adding the tests - it looks like we're using a div element for the input labels instead of a <label>

const renderLabel = ({ label }) => (
  label ? (
    <div style={labelStyle}>
      <Text>{label}</Text>
    </div>
  ) : null
);

I wonder if instead of using a <Text> component for this we could use the native <label> component? That way screen readers have an easier time knowing which label is associated to which input.

Here's an example of how we might do that:

const renderLabel = ({ label }) => (
  label ? (
    <label for={id}>{label}</label>
  ) : null
);

The only thing tricky about this is that I believe we'll need a unique id for each instance of the input in order to associate the label with a particular <input>

Remove the global font-family setting on the storybook config

https://github.com/bufferapp/buffer-components/blame/master/.storybook/head.html#L4

Set fontFamily on all components that need it

https://github.com/bufferapp/buffer-components/blob/master/style/font.js#L1

As per the design spec by @thomasdunnuk and @suprasanna, for the schedule setting, we're looking to add a colon between the hour and minutes. I've highlighted the area of affect this change will have on any and all instances of InputTime in our editing doc.

Proposed design:

My local copy of the Buffer Style Guide has the new UI from Dave O.'s style guide Sketch file. Rather than working on pushing that live, it feels great to migrate those changes to the Button component itself here.

We're finding some undesirable effects caused by having our icon set as a font such as undeterminable icon element sizes (due to font properties and values), and so it feels like a signal to explore SVGs instead.

Description

To add a disabled state to the button when the disabled attribute is present. It doesn't seem that we have this on our style-guide. We'd want this for all styles of the button.

We can use the attribute selector to target this:

.Button[disabled] {
  // ...
}

From Slack:

Wanted to bring up an accessibility thought around our date pickers! I think this is mentioned in Inclusive Design Patterns, but a common a11y pattern for date pickers is to also include a combo box or text input that users can type their date in directly - this lets users on screen readers skip having to keyboard navigate through all the dates in a month! We just got some more feedback about this from a blind user who is having a hard time scheduling posts in Buffer because our current Date Picker doesn’t include a combo box: https://secure.helpscout.net/conversation/359539095/1081589/

Here's an example of how this can be implemented in react-day-picker:
http://react-day-picker.js.org/examples/?input

Here's Dave's mockup of what this might look like! :D

While the Buffer Components Library renders CSS variables fine, in buffer-web rgba(#HEX, .1) is an invalid property. Feels great to roll this in a 0.1.1 patch!

When we've got multiple (let's say 40) components and we only need to consume 1, how do we pull in 1 component without pulling in all 40 and bloating the code?

Forcing font size makes it difficult for users with vision impairments

This piece of UI is now in our schedule setting and Org. Admin. Feels like a good spot to perhaps add this as a component to our component library!

Design:

https://github.com/jbovenschen/storybook-addon-a11y

We need to create a component that will provide an "overlay" piece of UI that will allow modals and other content to sit on top of it while still making the UI underneath the Overlay slightly visible.

Purpose

After a quick catch up with @docal56, it feels like we want to make three changes with the appearance of this component:

• modify the font-weight from 600 to 400
• introduce a container that sets the inner content to be 61.25em (980px equivalent)

Things to Note

Our external pages use the same UI so any changes we make here will be replicated and made on buffer-web. 👍

Review

Hey, @hharnisc! Feels great to perhaps review how these changes might impact the use of this component in the Buffer video service! 😄

What happens when there is a conflict in react dependencies between the component library and the app consuming project? Seems there are a few possibilities:

• Webpack packages both versions side by side
• Only the new version is packaged with webpack
• Breaks entirely
• ???

@Alex-ray made a great point that the styles being inherited by components from buffer-components being used in buffer-web seem to be having some interesting effects, which causes us to override them in buffer-web. It feels great to visit this one and see how we can detach this inheritance of typography completely.

Performance

With the performance optimizations browsers make when loading stylesheets and rendering the dom (layout + paint) caching styles between components with the same classname, would ReactCSS not allow us to take advantage of this built in browser help? Does rendering all the styles in the DOM slow down React rendering times for large apps?
https://byjoeybaker.com/react-inline-styles
https://vineetgupta22.wordpress.com/2011/07/09/inline-vs-internal-vs-external-css/

Writing CSS v. writing JS CSS properties

Is it easier for designers and devs to write CSS as CSS modules or are people comfortable writing the js properites? ex. border-radius v. borderRadius

Re-use of base CSS or global CSS for elements

Where does global element/base css exist for things like body, h1? What about normalize.css?

Other questions?

All components that use the noStyle config of the Button component don't render any text in Safari when using lineHeight: 0. Setting lineHeight like this allows instances of Button with an Icon as its only child to have Icon perfectly center. It feels like we might need to explore an alternative solution with perhaps a last resort being a child-type specific config of Button.

Since the Select component uses a form element (<select>), it requires a label.

This has got me thinking if it might be useful to have some sort of option or additional component that would allow us to hide a form element label visually but keep it discoverable to screen readers? It seems like there might be a few places where a form element doesn't necessarily need a visual label because the element makes sense contextually to visual users, but would be helpful for users on screen readers?

Allow setting button color and background in normal and hovered states