Coder Social home page Coder Social logo

microsoft / fluent-ui-react Goto Github PK

View Code? Open in Web Editor NEW
432.0 36.0 57.0 72.33 MB

An ecosystem for building highly customizable enterprise class user interfaces.

Home Page: https://aka.ms/fluent-ui

License: MIT License

TypeScript 99.02% JavaScript 0.82% Shell 0.11% HTML 0.05%

fluent-ui-react's Introduction

Fluent UI

👉 microsoft/fluent-ui-react has moved to OfficeDev/office-ui-fabric-react/packages/fluentui.

This does not affect the packages of fluent-ui-react, which will continue to be developed and published under https://www.npmjs.com/package/@fluentui/react.

FAQ

Why the move?

We're in the process of converging UI projects at Microsoft under the "Fluent UI" banner to simplify the dev story. In the process, we're making performance improvements and enabling greater interoperability of these components across more places and platforms at Microsoft.

What's happening with Teams support?

@fluentui/react v0.x.x has been the official set of components for Teams. This is still the case and no support is being dropped.

What's happening with Fabric?

The Fabric packages will also be renamed to @fluentui/react v7.x.x. The officedev/office-ui-fabric-react repo will move to microsoft/fluentui shortly.

Where did the fluent-ui-react docs go?

For documentation on the fluent-ui-react code, please go here: https://aka.ms/fluent-ui.

Where do I log issues?

Log them here: https://github.com/OfficeDev/office-ui-fabric-react/issues. The Fluent UI v0 tag can be added to help idenfity issues specific.

Where do I commit PRs?

Submit PRs here: https://github.com/OfficeDev/office-ui-fabric-react/pulls.

fluent-ui-react's People

Contributors

alinais avatar athurman avatar bcalvery avatar codepretty avatar deweybot avatar dpkwhan avatar dvdzkwsk avatar eanplatter avatar ecraig12345 avatar fracmak avatar greenkeeperio-bot avatar hughreeling avatar jeffcarbs avatar joheredi avatar josie11 avatar jurokapsiar avatar kolaps33 avatar kuzhelov avatar kyleturco avatar layershifter avatar levithomason avatar lucivpav avatar miroslavstastny avatar mnajdova avatar notandrew avatar seankeating avatar silviuaavram avatar sophieh29 avatar tadeploy avatar tarang9211 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fluent-ui-react's Issues

feat(Avatar): icon's color customization mechanisms are limited

Feature Request

Problem description

Currently the Avatar's icon color is entirely defined by 'presenceStatus' (for example, for the 'Available' status green color is used). The following problems arise as a consequence

  • there is no way to customize these colors by theming
  • there is no way to decouple Avatar component from the 'presenceStatus' concept - while status aspect of Avatar could be seen as something more general, not about just providing 'presence' status - it could be about providing 'role' status of the person, as a simple example.

Proposed solution

Customization mechanisms for Avatar's icon should be introduced. At the very least, there should be a way to customize

  • icon's colors
  • icon itself (whether it is a 'shevron', 'pause', 'play', etc)

Accessibility for Menu/MenuItem

Bug Report

Steps

Open Stardust components page, navigate to Menu examples and observe HTML generated for both Shorthand and Children API.

Expected Result

According to ARIA best practices as well as to our testers, the menu structure should have following structure:

      <ul role="menu" aria-label="About">
        <li role="none">
          <a role="menuitem"
             href="mb-about.html#overview"
             tabindex="0">
            Overview
          </a>
        </li>
        ...
      </ul>

Note: role='none' can be replaced with role='presentation' which is supported by more browsers. <a> can be replaced with <button> or <div> for other purposes.

It is important that the click handler is on the element that is focusable both by the browser as well as by the screen reader. This means it has to be either a naturally tabbable element or element with tabIndex >= 0 and it has to have role='menuitem'.

This can be achieved by small modifications to current MenuItem.tsx code for Shorthand API:

  • <li> needs to be marked as role=presentation
  • onClick handler needs to move from the root element to <a>
  • <a> will need to be marked as role='menuitem' (which will be applied by the behavior)

Is there a way to achieve this in the Child API?
Or if user provides child components then it is his responsibility to conform to the standard approach and we just need to document this?

Reference: https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html

Actual Result

<ul class="ui-menu a u b c d e f">
  <li class="ui-menu__item v g h i j k l m n o p q r w x y z" onclick='...'>
    <a class="ui-menu__item__anchor s t">Editorials</a>
  </li>
</ul>

Version

0.2.3

Testcase

Rename 'rest' to 'unhandledProps'

From Levi:
rest is carryover from Semantic UI React. It came from doing const { size, ...rest } = this.props. However, since it is really the return of getUnhandledProps, it probably makes sense to call it unhandledProps. This is also pretty clear as to what it is.

feat: Base implementation for Grid

Feature Request

OP: @levithomason linked from react-old/issues/97

Grid

This API proposal is for creating a minimal base implementation of a Grid component. I propose this is done using CSS Grid syntax, respecting IE 11 shortcomings (no gap, no template areas).

Helpful resource: https://learncssgrid.com

API Proposal

columns (quantity)

A Grid can define an arbitrary number of columns of equal width.

<Grid columns='3'>  //=> { display: grid; grid-template-columns: 1fr 1fr 1fr; }
  <Box>1</Box>
  <Box>2</Box>
  <Box>3</Box>
</Grid>

A string or a number should be accepted.

image

columns (explicit)

A Grid can explicitly define columns and their sizes.

For now, this is simply using the grid-template-columns value syntax. Proposing we consider more useful abstractions later.

<Grid columns='90px 50px 120px'> //=> { display: grid; grid-template-columns: 90px 50px 120px; }
  <Box>1</Box>
  <Box>2</Box>
  <Box>3</Box>
  <Box>4</Box>
  <Box>5</Box>
  <Box>6</Box>
</Grid>

image

rows (quantity)

Note, unlike the columns I'm not proposing a way of defining an arbitrary number of rows. Rows are created automatically when columns wrap. Therefore, it makes no sense to say a Grid will have X rows ahead of time.

It may prove useful to be able to say "assign this value to all rows", however, I'm leaving this out of the base implementation proposal.

rows (explicit)

A Grid can explicitly define the sizes of its rows.

For now, this is simply using the grid-template-rows value syntax. Proposing we consider more useful abstractions later.

<Grid rows='50px 100px'> //=> { display: grid; grid-template-rows: 50px 100px; }
  <Box>1</Box>
  <Box>2</Box>
  <Box>3</Box>
  <Box>4</Box>
  <Box>5</Box>
  <Box>6</Box>
</Grid>

List item header does not have rem size

Bug Report

Steps

image

Expected Result

Nothing should change with the List, it still should look the same:
image

Actual Result

The header of the list scales with the body font-size, but the rest of the list does not. That happens because the header uses the body styling and not its own rem based styling. Stardust should probably not enforce its consumers to specify 1rem in their body font-size.
image

Version

0.2.6

Add accessibility rules validation for docs examples

Add accessibility checks for HTML rendered by component examples

It would be great to provide docs user with a feedback about accessibility correctness for the component example code (potentially edited). Currently we have htmlIsAccessibilityCompliant test (which relies on aXe lib - #156), and it seems that its functionality can be reused to achieve this goal.

[RFC] Popup position

Popup position

We are currently implementing a Popup component (#150) and in the first version of the API we're still undecided how to define the position of the popup relative to its trigger element (the element that created the popup and offers relevant info about positioning it).

Problem description

In our terminology, element has four sides - start, end, top, bottom.

In current proposal that is introduced by #150 the popup's positioning is defined by the position prop, a string that can take the following values:

'top-start' | 'top' | 'top-end' | 'bottom-start' | 'bottom' | 'bottom-end' | 'before-start' | 'before' | 'before-end' | 'after-start' | 'after' | 'after-end'

As one can see, popup position consists of two words:

  1. the first one defines popup position relative to trigger element:
  • top
  • bottom
  • before
  • after
  1. the second one defines which side of the popup and trigger are aligned:
  • start in top-start and bottom-start means start sides are aligned
  • end in top-end and bottom-end means end sides are aligned
  • start in before-start and after-start means top sides are aligned
  • end in before-end and after-end means bottom sides are aligned

It is confusing that start and end are used for both vertical and horizontal alignment. This supports flex terminology (which uses start/end for both main and cross axis) as well as popper.js, but in Stardust context it collides with start and end which we use for left and right.

Other libraries examples

1. Popper.js popup

Valid placements are: 'auto' | 'top' | 'right' | 'bottom' | 'left'
Each placement can have a variation from this list: '-start' | '-end'

2. MDN web docs: Popup Guid: Positioning

Single Word Alignment Values Example
before_start: The left side of the popup is aligned with the left side of the anchor, and the bottom of the popup is aligned along the top of the anchor. Equivalent to topleft bottomleft screen shot 2018-09-10 at 15 08 04
before_end: The right side of the popup is aligned with the right side of the anchor, and the bottom of the popup is aligned along the top of the anchor. Equivalent to topright bottomright screen shot 2018-09-10 at 15 08 13
after_start: The left side of the popup is aligned with the left side of the anchor, and the top of the popup is aligned along the bottom of the anchor. This value is commonly used for menu buttons. Equivalent to bottomleft topleft screen shot 2018-09-10 at 15 08 20
after_end: The right side of the popup is aligned with the right side of the anchor, and the top of the popup is aligned along the bottom of the anchor. Equivalent to bottomright topright screen shot 2018-09-10 at 15 08 26
start_before: The top edge of the popup is aligned with the top edge of the anchor, and the right side of the popup is aligned along the left side of the anchor. Equivalent to topleft topright screen shot 2018-09-10 at 15 08 32
start_after: The bottom side of the popup is aligned with the bottom side of the anchor, and the right side of the popup is aligned along the left side of the anchor.  Equivalent to bottomleft bottomright screen shot 2018-09-10 at 15 08 37
end_before: The top edge of the popup is aligned with the top edge of the anchor, and the left side of the popup is aligned along the right side of the anchor. This value is used for submenus. Equivalent to topright topleft screen shot 2018-09-10 at 15 08 41
end_after: The bottom side of the popup is aligned with the bottom side of the anchor, and the left side of the popup is aligned along the right side of the anchor. Equivalent to bottomright bottomleft screen shot 2018-09-10 at 15 08 47

3. Jquery popup overlay

1 2 3 4
horizontal center' / 'left' / 'right' / 'leftedge' / 'rightedge' 'center' Sets horizontal position. Options leftedge and rightedge can be used only for tooltips, and will align the tooltip to the left or right edge of the opening element (openelement).
-- -- -- --
vertical 'center' / 'top' / 'bottom' / 'topedge' / 'bottomedge' 'center' Sets vertical position. Options topedge and bottomedge can be used only for tooltips, and will align the tooltip to the top or bottom edge of the opening element (openelement).

4. JqueryUI popup

(default: "center")
Type: String

Defines which position on the element being positioned to align with the target element: horizontal vertical alignment.

A single value such as right will be normalized to right center, top will be normalized to center top (following CSS convention). Acceptable horizontal values: left, center, right.

Acceptable vertical values: top, center, bottom. Example: left top or center center. Each dimension can also contain offsets, in pixels or percent, e.g., right+10 top-25%. Percentage offsets are relative to the element being positioned.

5. Tippyjs popup

A tooltip can be placed in four different ways in relation to its reference element. Additionally, the tooltip can be shifted:
'Top' | 'Bottom' | 'Left' | 'Right' | 'Top-Start' | 'Top-End'
screen shot 2018-09-10 at 15 35 42

6. Bootstrap popup

Four directions
Four options are available: 'top, right, bottom, and left aligned.

Proposed solutions

Proposal 1

Without checking other libraries, we introduce new terminology:

  • for position: 'above' | 'below' | 'before' | 'after'
  • for alignment: 'start' | 'end' | 'top' | 'bottom'
  • add third word -aligned?

That results in combinations like:
position="above-start"
position="above-start-aligned"

Other ideas is renaming the prop to placement: that results in combinations like:
placement="above-start"
placement="above-start-aligned"

Proposal 2

Do we really need to combine the two into a single property? Wouldn't it make sense to leave them separate? Drawback is it allows conflicting combinations.

Proposal 3

Current proposal of #150

Proposal 4

See above: 2. MDN web docs: Popup Guid: Positioning

Prop-dependent variables

Feature Request

Where we are now

Agreed on the following task (#231 (comment)) to be solved first by trying to prototype each of the suggested approaches. Here are prototype links to try:

  • CSS-based approach prototype (#240)
  • JS-based approach prototype (about to come)

Problem description

After syncing up with Fabric there were some concerns raised around our taken approach to use props as variables function' argument:

// buttonVariables
(siteVariables, props) => ({
  ...
})

Proposed solution

Although a step related to make styling aspects to be completely a theme's area of responsibility is definitely a step in the right direction, there is need to discuss potential alternatives to proposed solution.

Please, consider this PR where discussion thread has started #207 - all related posts are cited here as well.

Why fela?

I am wondering the reasons why fela has been chosen instead of e.g. styled-components.

I guess fela brings state on top of styling - Never used it, so curious to know how stardust-ui uses it.

Getting error while importing from module themes/teams

Bug Report

Error is cannot find module @stardust-ui/react/themes/teams. Using Stardust version : 0.4.0. Branch Name: Tempbranchproviderissue
import {
fontFaces,
staticStyles,
theme
} from "@stardust-ui/react/themes/teams";
"

Steps

A clear and concise description of steps to reproduce the problem.
Steps to reproduce:
yarn install
yarn run storybook

Expected Result

The result that you expected.

Actual Result

The actual result that happened 💣

Version

0.4.0

Testcase

[RFC] Provider: Font sizes from Teams' theme siteVariables are too large

Bug Report

Steps

Provider: is now getting siteVariables from Teams' theme. Font sizes are too large.

Expected Result

The font sizes are as expected expected.

Actual Result

Font sizes are too large, with following changes, they look much closer to the existing Teams app:
bodyFontSize = "1rem" => "1.4rem"
htmlFontSize = "10px" => "14px"

Version

0.5.0

Provider type errors

Bug Report

Usage of Provider is triggering errors in the definition file of Provider (provider.d.ts).
There have been no issues in 0.2.6/0.2.7 when commonjs version was exported instead of es

Steps

import { Provider } from "@stardust-ui/react";
//just the import is triggering the errors

Expected Result

No errors.

Actual Result

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:19:47
TS1005: '>' expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:19:54
TS1003: Identifier expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:19:75
TS1144: '{' or ';' expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:19:98
TS1005: ';' expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:19:99
TS1109: Expression expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:20:35
TS1109: Expression expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:21:32
TS1109: Expression expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:22:24
TS1005: ';' expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:22:30
TS1109: Expression expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:23:13
TS1005: ';' expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:24:1
TS1128: Declaration or statement expected.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:20:5
TS7028: Unused label.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:21:5
TS7028: Unused label.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:19:47
TS7010: 'import', which lacks return-type annotation, implicitly has an 'any' return type.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:19:54
TS7006: Parameter '(Missing)' implicitly has an 'any' type.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:19:76
TS7008: Member 'IProviderConsumerProps' implicitly has an 'any' type.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:20:25
TS7011: Function expression, which lacks return-type annotation, implicitly has an 'any' return type.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:21:22
TS7011: Function expression, which lacks return-type annotation, implicitly has an 'any' return type.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:22:5
TS2304: Cannot find name 'componentDidMount'.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:23:5
TS2304: Cannot find name 'render'.

WARNING in [at-loader] ../../../node_modules/@stardust-ui/react/dist/es/components/Provider/Provider.d.ts:23:15
TS2708: Cannot use namespace 'JSX' as a value.

Version

0.3.0

RTL mode does not work properly

RTL mode does not work properly

Steps

  1. add marginRight: <some_value> style to any component implementation
  2. add a docs example that takes this component
  3. press the RTL button
    screen shot 2018-07-30 at 15 46 56
  4. inspect the component

Expected Result

CSS prop marginRight: <some_value> is changed to marginLeft: <some_value>

Actual Result

CSS marginRight: <some_value> does not change to marginLeft!

Version

0.2.3

Theme-defined icons support (including SVG, font-based)

Feature Request

Problem description

Currently it is impossible for theme author to define set of icons that could be rendered by Icon component. Specifically, if theme author would like to introduce icon foo and consume it in the following way with her theme being applied, currently there is no way to achieve that

<Icon name='foo'>

Proposed solution

Here is the plan we see to address this issue

  • introduce mechanics of consuming icons from theme
    • now is introduced for SVGs (#183), should be generalised for font-based icons as well (#243)
  • resolve aspects related to sizing (it should be possible to pixel-perfectly customize size of the icon)
  • support icon's outline/filled variants
  • support changing look of the icon on hover state

Avatar initials parsing should take long / special names into account

Feature Request

Problem description

In some cases, a name of a user may be too long or it may contain special characters. Consider the following examples:

name Initials in <Avatar /> in 0.2.3 Proposed initials
William Wilson Worlov WWW
image
WW
Barack Obama (Ex-president, USA) BO(U
image
BO

Proposed solution

We should think whether this is a problem of the Avatar component or of the developer using the component. I propose the Avatar component should try to parse these complex names, maybe with configurable flags (e.g., useShortInitials). With this flag enabled, the component would remove everything in brackets ((...), [...], {...}) and then use the initials of the first and last words only, i.e., removing all words between them.

[RFC] props vs variables boundary

I still don't have a firm understanding of what defines a boundary between props and variables. I am not proposing any change, I am just playing devil's advocate to make sure stardust architecture is correct. I am trying to define the boundary in order to be able to make decisions when designing component API.

A possible definition which makes sense to me is whatever is used in the component code belongs to props and whatever is used only for styling (=theming) should be part of variables because variables are part of the theme.

Button component example

Why is circular a prop? It does not affect component structure, it is used in theme only to make the button round.

For my custom theme, I need hexagonal button. Why am I not able to achieve that using the same semantics (<Button hexagonal ... />)? And what about the circular prop? Do I need to support it even if my theme does not provide circular button?

Red file names in VS Code?

Whenever I open a file in VS Code I'm getting warnings/red text, which is really difficult to ignore. It seems to be caused by the first line import React from 'react', which is showing the error [ts] Module '"d:/Dev/stardust-react/node_modules/@types/react/index"' has no default export..
image
Changing the first line of the file to import * as React from 'react' does fix it. Is this an acceptable change to make in the files I'm working in?

CSS in JS issues

We'll track CSS in JS issues we're having here and propose solutions later.

  1. Cannot switch to a different renderer (normal, rtl) during the life of the app #58
  2. We'll need to support multiple React roots on a single page.

Avatar status icon makes the whole component taller

Bug Report

Steps

Try modifying the <List /> example:
https://stardust-ui.github.io/react/components/list#types-list

  <List
    items={[
      {
        key: 'irving',
        media: <Avatar src="public/images/avatar/small/matt.jpg" />,
        header: 'Irving Kuhic',
        headerMedia: '7:26:56 AM',
        content: 'Program the sensor to the SAS alarm through the haptic SQL card!',
      },
      {
        key: 'skyler',
        media: <Avatar src="public/images/avatar/small/steve.jpg" status="Available" />,
        header: 'Skyler Parks',
        headerMedia: '11:30:17 PM',
        content: 'Use the online FTP application to input the multi-byte application!',
      },
      {
        key: 'dante',
        media: <Avatar src="public/images/avatar/small/nom.jpg" />,
        header: 'Dante Schneider',
        headerMedia: '5:22:40 PM',
        content: 'The GB pixel is down, navigate the virtual interface!',
      },
    ]}
  />

Expected Result

All three avatars should have the same height, aligning perfectly in the list.

Actual Result

The avatar with the status icon is taller and messes up the alignment.
image

With status icon (height 45.98px):

image

Without status icon (height 31.98px):

image

Version

0.2.3

Typings in dist are incorrect

Bug Report

This is an offline report submitted to me.

Steps

  1. create-react-app my-app --scripts-version=react-scripts-ts
  2. cd my-app
  3. npm install --save @stardust-ui/react
  4. Edit App.tsx to import { Header } from '@stardust-ui/react'
  5. Add the same Header tag as in the example documentation.
  6. npm start

Expected Result

The app should run.

Actual Result

image

Version

0.2.6

[RFC] feat: Accessibility

Accessibility

Why

  • Stardust is a flexible UI library that allows composition of components. Accessibility patterns are much more restrictive. We need a way of applying the restrictive patterns to the flexible UI components
  • Stardust should provide accessibility by default, but the developer using Stardust should be able to modify/override the behavior to fit his specific needs
  • All components need to be semantically correct
  • RTL has impact on keyboard navigation as it switches right/left arrow key functionality

What is accessibility

  • sufficient contrast in standard themes
  • high contrast theme
  • zoom
  • keyboard navigation / focus handling / focus highlighting
  • screen reader support for virtual cursor and narration

Proposal

Goal

  • each component must be accessible
  • each component should have correct color contrast and high contrast theme defined
  • component should have its own default accessibility behavior, which can be overridden from parent component if needed
  • accessibility behavior should be separated from the component, extendable and reusable
  • accessibility behavior should be easy to use

Behaviors

Component uses accessibility behavior to apply event handlers and aria properties to rendered HTML elements.

The accessibility behavior of a component is initially determined by the component type and properties.
User of the component (developer) can override this default behavior by providing a different behavior type in the properties of the component.

There are two parts of accessibility, which should be encapsulated in the behaviors:

  • aria-* attributes - specifies the set of attributes necessary for correct narrating by screen readers.
  • keyboard navigation - allows using the application without mouse, whenever user navigates with keyboard he/she should be able to see where the focus is. The focus can be trapped in some areas (e.g. modal dialogs).

Stardust will use Office UI Fabric FocusZone component for basic keyboard navigation (arrow keys, home/end).

On top of the basic keyboard navigatoion, behaviors can attach event handlers to the rendered elements. Component defines actions which can be called by behaviors
to change the component state or focus a particular element.

Once an action is executed based on the event handler, the default event propagation should be prevented.

Themes and color contrast

  • each component should have at least two themes: standard and high contrast, to support this we use CSS -in-JS technique
  • each component's color palette should be verified for sufficient contrast

Focus management

Office UI Fabric FocusZone does the basic focus management which contains:

  • setting tabIndex 0 to currently focused element and setting tabIndex -1 to other elements from the focus zone
  • moving the focus according to the arrow keys pressed

On top of the basic focus management specific handling needs to be added for:

  • focus trap - when focus is trapped inside of a dialog, all other focusable elements need to be prevented from getting the focus either by handling tab key events or by setting their tabIndex to -1. In addition to that, main container needs to have aria-hidden='true' to prevent the screen reader from reading anything else than the current dialog.
  • focus stack - focus should return to the previous focused element if popups or modals were dismissed. To achieve that, Stardust will allow sending an onDismiss callback to relevant components and the components will call the callback when they are closed/removed from DOM.
  • focus indicator - used to highlight focus when application is in the keyboard mode

Implementation

The idea behind accessibility behaviors is to decouple accessibility logic from the component and make it reusable, easy overridable and extendable.

Behavior is either a plain javascript object or a function that transforms props into such object. The object contains attributes and keyHandlers maps for each component part, for example:

export const ButtonBehavior: Accessibility = (props: any) => ({
  attributes: {
    root: {
      role: 'button',
      'aria-hidden': false,
      'aria-disabled': !!props['disabled'],
    },
  },
})

props in this case is combination of the component's props and state. This allows the behaviors to be framework agnostic and more robust. (If a property moves from props to state, the behavior will not need to be changed.)

Stardust framework should provide a set of predefined behaviors. Users can add their custom behaviors by registering them to AccessibilityFactory using the static registerAccessibility(name: string, accessibility: Accessibility) method.

The component needs to define its default accessibility in defaultProps:

  public static defaultProps = {
    as: 'button',
    accessibility: AccessibilityType[AccessibilityType.button],
  }

If the accessibility behavior depends on the props or state of the component, the component should instead override getDefaultAccessibility method:

  getDefaultAccessibility() {
    return this.props.selection
      ? AccessibilityType[AccessibilityType.selectableList]
      : AccessibilityType[AccessibilityType.list]
  }

The evaluated accessibility object is passed to the component's renderComponent method:

  public renderComponent({ ElementType, classes, rest, accessibility }): React.ReactNode {
    ...
    return (
      <ElementType
        className={classes.root}
        disabled={disabled}
        onClick={this.handleClick}
        {...accessibility.attributes.root}
        {...rest}
      >
        {getContent()}
      </ElementType>
    )
  }

{…rest} goes after behavior generated attributes, to give more flexibility and allow to override anything generated by the behavior if developers need it.

Whenever component changes its state, the new aria-* attributes will be provided back to the component by the accessibility behavior.

Every component that can consume accessibility behavior, needs to be tested using handlesAccessibility test helper:

  handlesAccessibility(MenuItem, { defaultRootRole: 'presentation' })
  handlesAccessibility(MenuItem, { defaultRootRole: 'menuitem', partSelector: 'a' })

Supported client/screen reader combinations

  • Win/Desktop - JAWS
  • Win/Chrome - JAWS
  • Win/Edge - Narrator
  • Win/Firefox - NVDA
  • Mac/Desktop - VoiceOver

Glossary

Component - Stardust (react) component
Accessibility behavior - Javascript function,object or class that defines the behavior of a component
Element - HTML element rendered by the component
Event - HTML event (for example keydown)

[RFC] Naming of <Label> and <label> relative to an Input component

Feature Request

Problem description

Inside of an Input component we have the concept of a Label component which attaches to the front or back of an input. This is different than the native <label> which appears above an input (or to the left if the input is inline). This leads to confusion for the user, especially when using the shorthand API. When I set something as the label prop, am I setting the html lowercase <label> or am I passing attributes to a Label component.

Proposed solution

I think we should rename the Label component itself, relative to Inputs. This is going to reduce confusion in both discussion and semantics, but also simplify how be define these elements in the shorthand API.

Bootstrap calls these elements addons. That might be a good place to start. They also have the concept of prepend/append for positioning. I think we could just use addonPosition and "before"||"after"

Any other naming suggestions welcomed. I feel like it is early enough on that any challenges to be addressed in this name change can be handled fairly easily.

Add MenuItem disabled prop

Feature Request

As a result of #83 , it is required for the MenuItem Component to handle the disabled prop and act accordingly.

Problem description

The disabled prop has been added to MenuItem, in order to be used to add the aria-disabled attribute on the element. However, adding this prop should trigger the actual disabled behaviour for the menu item, similar to how Button behaves, for instance.

Proposed solution

Provide functionality to the MenuItem component in order to make it act similarly to Button when it receives the disabled=true

[RFC] Radio - create group options and add event handlers

Feature Request

Problem description

A clear and concise description of what the problem is. Ex. I have an issue when [...]

Proposed solution

A clear and concise description of what you want to happen. Add any considered drawbacks.

MVP

[RFC]feat(Avatar): Cross Compatible Image Clipping

How to accomplish Cross Platform Compatible Image Clipping
(for Avatar)

Problem description

The desired visual treatment for the Avatar in Teams is to have the background show through the gap between the "presence" icon and the image. Currently in Teams we fake this by passing the background color to the avatar so it can draw a correctly-colored circle behind the presence indicator. If you change the background color of the element behind the avatar you can see this trickery:
image
(current on left, desired on right)

The current approach is a hack. It works only with solid color behind the avatar. A gradient, image, or video background will reveal the border around the presence indicator. Passing in the background color also introduces excessive css and the possibility of bugs. It is also limited to round presence indicator (badge?). Furthermore, the current person avatar is a circle which is accomplished using border-radius (and a group is a square with rounded corners, also done via border-radius). This breaks down further when you consider the bot avatar is hexagonal, which can't be accomplished with border-radius, and the shape of the presence icon is also limited to a circle (or rounded square).

Solution?

An obvious solution for this is the CSS "clip-path" property. However it is not implemented in IE/Edge.

With CSS clip-path not being an option, I think we could still make a cross-platform solution by rendering the avatar image within an svg as the background of a shape. The shape could even be included as part of the theme. It is even conceivable that we could render the presence icon within the same svg, like this:

<svg …>  
    <path d="{avatar shape/path from theme (influenced by type, size, etc)}"  
          fill="url({magically put person,group,bot image here})"></path>  
    <path d="{presence shape/path from theme (influenced by state, size, etc)}"  
          fill="{color influenced by state}"></path>  
</svg>

With this approach we could hopefully systematically render more complex shapes for the avatar and the presence indicator, with the background showing through, a la:
image

I'm working in a local branch trying to make a proof of this, but how to render an inline svg and pass in the image in a usable way are at the outer boundaries of my skill. I'd like to know if this seems feasible and I'll take any input on this. Thanks.

State management in-scope?

Upon current scope for stardust-ui (*), is state management (redux...) a target? This would be a nice needed feature.

(*) Creating Components, CSS-in-JS, Theming, Component API, Shorthand API, Event Stack, HTML Font Size, Parent Child Coupling

[RFC]theming: Theme-provided or theme-restricted Enumeration?

Theme-provided or theme-restricted Enumeration?

How can a theme restrict usage of possible variables, or provide a custom range of variables. And how can other theme-specific information be provided in a more abstract/customizable/flexible way?

Problem

Right now there are multiple enums which are defined in src. Specifically there are (for the Text component) Sizes and Weights. I can easily imagine there will soon be additional application-specific enums, such as AvatarSizes, PresenceStates and other components as well.

The basic questions are: What happens when the design team providing a theme wants to limit the number of Text sizes available, or wants to "outlaw" certain font weights? How do they do that? What happens if a size/weight becomes deprecated? What about making various combinations of sizes/weights allowed or disallowed?

Related question: What about things that are somewhat more application-specific, like in the case of Avatar, AvatarSizes and PresenceStates? Would it be possible to make the theme (and business logic) provide the data for those? For AvatarSizes Stardust might say "we need S, M, L and XL avatar sizes" and it would be nice if the theme definition could say "M is not allowed, don't let M be used." But what about PresenceStates? Presence seems very specific, the idea of "Available" or "Away" is pretty heavily tied to a chat app... What if some other product that uses Stardust has representations of people and wants to use Avatar, but has very different ideas of what an avatar's "state" could be? If we've hard-coded "presence" enum to be specific to our application (available, away, etc) that doesn't seem to be a very open/flexible system.

Another related question: Would it be possible to streamline/simplify the amount of redundancy between the siteVariables and the multiple component-specific files? Using Text as an example again: siteVariables feeds into textVariables, which feeds into textStyles files? Having a more systematic way to provide/consume the styles might streamline the existing approach.
image

Possible solution:

Could an interface or json object format be a solution for this? Stardust could have an ITextStyle interface, and the theme could provide text style objects that conform to the interface. One of the properties the interface requires could be a "valid" or "deprecated" Boolean. Perhaps another "object" that the theme could provide is a "map to" which would tell stardust what sizes/weights are valid and/or what sizes/weights to substitute?

A similar approach could also be used for elements of avatar. AvatarType could include the name-type and shape of the avatar and the AvatarState could include the name-type, shape, and color of the "presence."

I do see that the TextVariables.ts file defines an Interface, but that file is within the theme, so it isn't exactly telling other themes how to interact with Stardust. Simultaneously the Text component in Stardust src has a pretty direct/explicit/inflexible relationship with what is defined in the various theme files for Text.

Comments please

Menu item `href` breaks focus (necessary to TAB twice)

Bug Report

Steps

  1. Go to https://stardust-ui.github.io/react/components/menu, version 0.5.0.
  2. Edit the first example by adding href: '#', e.g., with the following code:
    import React from 'react'
    import { Menu } from '@stardust-ui/react'
    
    const items = [
      { key: 'editorials', content: 'Editorials', href: '#' },
      { key: 'review', content: 'Reviews', href: '#' },
      { key: 'events', content: 'Upcoming Events', href: '#' },
    ]
    
    const MenuExample = () => <Menu defaultActiveIndex={0} items={items} />
    
    export default MenuExample
    
  3. Try keyboard navigation (TAB key) on the menu.

Expected Result

Pressing TAB moves you to the next menu item, Shift+TAB to the previous one.

Actual Result

It is necessary to press TAB or Shift+TAB twice for each menu item. The reason is that using href changes the menu item into <a>, so there are now two nested <a> taking focus one by one.

Version

0.5.0

[RFC] Decouple variables passed to child components from parent component's logic

from @levithomason post:

Motivation

Any variables or styles used directly in a component's logic implicitly become part of a global theming interface.

All themes will have to implement variables.typePrimaryColor, for instance, in order for this to work. Additionally, we are removing the styling from the theme and baking it into the component instead.

We would like all theming values and theming logic living in the theme's files. This way, each theme is free to choose the values and logic behind their styles. The question is how?

Proposal 1 - Component part variables

Component variables files could define variables for each component parts as well. Then, variable values and logic for component parts can be left to the theme and not dictated to all themes by the component. Here's an example of the Button theme defining an icon part in its variables.

// themes/teams/components/Button/buttonVariables.tsx

export default (siteVariables) => {
  const variables = {
    color: undefined,
    typePrimaryColor: siteVariables.white,
    typeSecondaryColor: siteVariables.black,
  }

  variables.icon = {
    color:
      type === "primary"
        ? variables.typePrimaryColor
        : type === "secondary"
          ? variables.typeSecondaryColor
          : variables.color
  }

  return variables
}

Now, the component simply implements a contract that says "we pass variables[part] to each component part":

// Button.tsx

Icon.create(icon, {
  defaultProps: {
    variables: variables.icon
  }
})

This would also allow us to do this consistently for all components, including the styles for each component part. That then would allow us to write a conformance test for it. This would make the API easier to understand and work with as well since there is only one concept, "components pass variables/styles to each component part".

Proposal 2 - A high-level theme interface

This proposal would introduce a new concept. Something like a lightweight theme interface that is allowed to pass between components. It would consist of backgroundColor, foregroundColor, and perhaps an accentColor initially (names and keys are inspired by present convergence talks with several teams at Microsoft).

The Button in this case would define these three values for its bounds. Then, they would passed to the Icon.

/cc @levithomason, @miroslavstastny

Purpose of PropTypes and Interfaces

Looking through the Button source, I see that there is a Typescript interface for it's props as well as redundant usage of the PropTypes package.

Is there a reason for using both?

[RFC] Button focus outline/glow styles

Current

Today when focusing on a button we see the native browser focus styles as seen below in these screenshots:
image
image
image

Proposal

I propose that we remove these default :focus styles and normalize the focus style across all browsers. There were similar focus styles in Semantic UI which were slightly different than :active and :hover.

Proposed solution

For now I propose that we use the same darken/lighten function ratios that Semantic UI used for changing the default color for these pseudo classes.

As far as I can tell:
default => #E0E1E2
:active => #BABBBC
:hover => #CACBCD
:focus => (same as :hover)
.active => #C0C1C2 (I think the active class/prop is probably already handled today. This is for reference)

For templating purposes I think all styles below "default" should be derived by darken/lighten functions from the default background color.

Note

I noticed that the Input component currently does not have a focus style at all. I can open a separate issue for that to discuss, but from an accessibility standpoint we should have those styles there if we have disabled the native styles for :focus.

I understand Stardust is a WIP and very early so apologies if I am stepping on anyone's toes if this is already being worked on. However, if it is not I am happy to open up a PR with some initial work here for discussion.

Add typings for component props

Feature Request

Problem description

We are missing or have removed props typings in our components.

Proposed solution

See #33 fo the discussion and agreement on this proposal. Let's do this one component and PR at a time to give room for addressing issues that will arise.

  1. Add props typings only for handledProps as this is most helpful to the user.
  2. Make all props interfaces extensible so users can pass any prop value they wish (also aligns with our practice of spreading rest props).
  3. Provide a *Strict named interface which is not extensible. This allows users to lock allowed props to strictly those supported by the component if they wish, see Semantic-Org/Semantic-UI-React#2836. Our props interfaces will union this interface making it extensible.

TODO

feat: Extract the Item Layout from the List.Item

(Moving from old repo)

Layouts are invisible and are used to place components into a specific arrangement of areas. We currently use the "ItemLayout" component in the ListItem to arrange its parts (media, header, content, etc).

This layout will be used in many other places, such as menus. Stardust will contain a few helpful layouts, of which this is one.

The item layout should be exposed at the top level of the API. We should add a category called "Layouts" just as we currently have "Components". We'll place all invisible Layout components here for now.

[RFC] MenuItem Children API

When implementing menu accessibility (#61), MenuItem (which by default renders as li > a) was modified and onClick handler as well as several styling were moved from li to a.

That works correctly for ShorthandApi, but unfortunately it breaks ChildrenApi. It was agreed previously that <Menu.Item>children</MenuItem> renders as <li>children</li>.
That worked previously as all the styles and onClick were on the li, but it is broken now.

I was thinking about splitting ListItem to ListItem (which renders as li) and ListItemLink (which renders as a). I played with the code to test this approach and it seems to work. The only problem I see is that a developer must pass the same props to several components:

<Menu>
  <Menu.Item>
    <Menu.Item.Link>
    </Menu.Item.Link>
  </Menu.Item>
</Menu>

Now if you want to make the menu to be vertical, you must add vertical to all Menu, Menu.Item and Menu.Item.Link. For an active item, you must add active to both Menu.Item and Menu.Item.Link.

What is our plan for supporting Children API?

[RFC] Typescript type checking options

Stardust uses Typescript, but all it's type checking options are disabled, which kills a lot of Typescript's power.
Enabling (some of) the checks would make the code better and it'd easier to enable them in the early stage of the project.

I went through the list of compiler options which could be worth considering and also checked tsconfig in other projects which use Typescript.

option project A project B ionic/react vscode/src rxjs description
noImplicitReturns   true true true true Report error when not all code paths in function return a value.
noImplicitAny (1)   true true   true Raise error on expressions and declarations with an implied any type.
noImplicitThis (1)       true true Raise error on this expressions with an implied any type.
noUnusedParameters   true true     Report errors on unused parameters.
noUnusedLocals   true true true   Report errors on unused locals.
alwaysStrict (1) true     true   Parse in strict mode and emit "use strict" for each source file
strictNullChecks (1)           In strict null checking mode, the null and undefined values are not in the domain of every type and are only assignable to themselves and any (the one exception being that undefined is also assignable to void).
strictFunctionTypes (1)         true Disable bivariant parameter checking for function types.
strictPropertyInitialization (1)           Ensure non-undefined class properties are initialized in the constructor. This option requires --strictNullChecks be enabled in order to take effect.

(1) part of --strict
Default value for all options is false.

Can we think of what would make sense to be enabled?

[RFC] Alternatives to Awkward Variant Modifiers

Linked from stardust-ui/react-old#2.

Feature Request

Problem description

In Semantic UI V1 we supported modifiers/variants such as:

<Button basic />        // this is cool
<Button basic="very" /> // this is not

The problem with this is that it's extremely unintuitive, reads awkwardly, and overloads what should be a boolean or otherwise mutually exclusive property (basic).

Proposed solution

This issue is designed to encourage conversation around alternatives to this problem. One simple idea would be to support something like:

<Button basic />
<Button veryBasic />

Better ideas are encouraged.

Docsite: watch issues

gulp watch does not pick changes on Windows

  1. On Windows, run yarn start
  2. Edit component source
  3. build:docs:docgen should be triggered, but nothing happens

The reason is that the watch path contains backslashes as path.resolve(), which is used to construct it, uses backslashes on Windows.
According to documentation glob pattern must contain forward slashes only.

Incremental build breaks examples menu

For each component single JSON file with a list of examples is built from multiple index.tsx files.
When one of the files is changed, watch triggers incremental build for the single changed file, and the resulting JSON is overwritten with data from that single file only.
(Have types and variants examples, update types' index, all variants are now missing in example menu).
This can be solved by adding gulp-remember to the watch pipe.

[RFC] API for component parts, shorthand, and variants

👉 I've scoped this discussion to icon to illustrate the point, but the concept applies to all props.


Problem

We need to solidify our API pattern for dealing with the icon prop. The prop name icon can mean different things in different contexts. It also creates conflicting APIs in some cases.

Consider all the forms of icon in the API currently:

Icon parts

Component parts are named parts within a component. Example, a Button can contain an icon, therefore, there is an icon part of the button.

The parts of a component standardize the areas that we target for styling, accessibility, and shorthand props.

Icon shorthand

We have shorthand props to make defining component parts, like icon, very simple and powerful:

<Button icon='user' />
<Button icon={{ name: 'user', color: 'red' }} />

Icon component variants

Here is where we hit an issue. Some components have a variation or type of the name "icon".

There is a difference between a component "containing an icon" and a component that is an of the type "icon".

See some examples
Header "containing an icon" vs an "Icon Header" type Header...

image

image

A "Button containing an icon" vs an "icon button". Notice the box model changes to fit the icon..

image

The list of components with special formatting for the icon only case continues.

API

Currently, we use a boolean prop of the name icon to signify the icon variant:

<Button icon />
<Header icon />
<Menu icon />

The issue is that you cannot simultaneously define an "icon part" with shorthand and specify the "icon variant" with a boolean. Passing any value to icon={...} in order to define the icon itself negates the ability to pass a boolean to specify if the component is of type icon or not.

Proposals

We need a different name for signifying the icon variant. The icon prop should be used for defining the icon only.

  1. iconOnly - this works in cases such as the Button and Menu where you are saying "this component contains an icon only". However, it fails in cases like the Header where the icon variant can coexist with other content, just formatted differently.
  2. type="icon" - scoping the type or variant works in all cases, but conflicts with other props like <Input type="" />.
  3. variant="icon" - This also works but seems to push us toward moving all variants into this enum. That breaks type safety and makes it difficult to compose multiple variants like <Menu variant="vertical icon".

We need more ideas and a robust solution to dealing with names that conflict across component type, shorthand, and variants. Feedback welcome!

[RFC] Using "fitted" for spacing concerns

This RFC was raised in regard to the Icon's xSpacing prop, see #22.

Proposals

  1. Use start and end for all APIs that have left/right needs.
  2. Borrow the concept of fitted from Semantic UI React.

Reasoning

start/end

  1. There is CSS precedence to consider. before/after are used exclusively in CSS pseudo elements where additional content is inject before/after some existing content. Start/end are used in many CSS properties (alignments, grids, flexbox, etc) to specify a physical location of an element.

  2. The <Layout /> currently uses start and end terminology to avoid the RTL issue with left and right names. Introducing before/after would introduce conflicting terms for the same ideas. We should normalize the naming. This would make our API more consistent and more predictable.

  3. The terms start/end can be applied to more cases than before/after.

fitted

  1. We want to strive to use natural language in our APIs. This allows them to have room for flexibility, while leaving implementation out. It also makes the API more portable between developers, designers, and management. It is closer to the way we talk about UIs, making it easier to use and internalize.

  2. The prop fitted loosely describes the appearance or format of a component. This leaves us free to adjust any CSS values necessary for the component to appear fitted. Fitted might mean different things in the context of different components. An icon does not achieve "fitted" in the same way a menu item would.

Precedence

This concept is used in many SUIR components. It has useful precedence and vetting there. It sometimes affects padding, sometimes margin, sometimes it is applied to one side, or to both sides of an axis. The important thing is that there is only one high-level natural language term required, "fitted", to support all of these cases.

A few examples:

Icon

image

Menu

image

Vertical Menu

image

Divider

image

[RFC] Provide merged props and state to Styles and Accessibility

Feature Request

The feature is meant to provide a unified object of the component's props and state in the context of Styles and Accessibility.

Problem description

So far, in both the cases of Accessibility and Styles, it was required that we have access to both state and props when applying custom behaviour or styles to the component.

The following scenarios should be considered as motivation for this feature:

  • accessibility: we need to provide an aria-checked to a checkbox, depending on its check state.
  • styles: we have hit the issue where we need to differentiate focus source (e.g. keyboard or mouse) so we can apply a different style to the component. If the focus comes from the mouse, this is reflected in the component's state, and then we need to apply different style (removing the focus ring) based on that.

Proposed solution

  • unified (merged) object of props and state should be passed as argument to component's style functions, as well as to the accessibility behaviours.
  • if there is a property that is common for both state and props objects, the one from props will override the one from state).

Which name should be used for merged object?

Currently we are using props as name for the arg that is passed to style function, and the same for the one that is passed to accessibility behavior. For the sake of not introducing misleading associations with React domain (this will quite loudly apply to style functions, where props arg will contain props+state data) it is better to consider another name for it. Proposed options so far:

  • properties (or componentProperties)
  • data (or componentData)

Nested lists

Feature Request

Nested (closable) list

Problem description

Even though Accordion does conform ARIA best practices and renders correct HTML from this point of view, we were not able to successfully use it in the nested lists use case (similar to https://stardust-ui.github.io/react/components/accordion#variations-list)

The HTML structure does not allow the screen readers to navigate correctly using virtual cursor.

To achieve the correct navigation, the structure needs to be changed in a way that resembles nested lists:

<ul id="main" style="list-style-type:none">
  <li><a href="#">Header 1</a>
    <div class="panel-content">
      <ul>
        <li><a href="#">item 1</a></li>
        <li><a href="#">item 2</a></li>
        <li><a href="#">item 3</a></li>
      </ul>
    </div>
  </li>
...
</ul>

Proposed solution

Either add a new variant of Accordion that renders this nested structure or create a separate component that allows that.

Menu width customization mechanisms are limited

Feature Request

Problem description

Hardcoded width for Menu is used by default (100px) - so that, as a consequence, vertical menu is always rendered 100px by default.

Proposed solution

Remove hardcoded width and make menu always taking the size of its container element.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.