prismatik / dendritic-ui Goto Github PK

Babel 6 does not support default export by default and instead offers this as a plugin

Should we cater for this? For the most part, I think we'll be using ES6 modules, but if we do have to require this it'll be using the icky 'default' key:

const RedbeardUI = require('redbeard-ui').default;

Ain't no thang to include it, just don't know if it's a thang we want.

Thoughts?

Now we have a designer onboard for the project, should we continue managing this solely via Github issues? Or should we move this to JIRA?

Let's talk about JIRA for a moment...

Moving to JIRA could help realise this project as something real - in the sense that we should properly organise, prioritise and manage resource/time for it. It will help bolster it's importance among other paid projects I think.

It could also be an excellent way of exposing more visibility to other departments about the priorities of redbeard-ui, and what's being worked on - and why - and how that will provide value for client work.

One downside - maybe? Depends on how you view it - is that it would need to be properly project managed I believe. We haven't really sorted out how that works with these kind of projects yet.

Also adding to JIRA might see the project perceived as less "lean"? Like, maybe a little less approachable if a developer just wants to muck in and do some things, due to there being more process added by using JIRA. I don't know, just a thought.

Thoughts?

As per initial description in #4

• <Spinner /> should fit nicely into buttons and other elements. should obey the em font size

At this point we seems to going to use font awesome. so we need an Icon component and a setup for the font-awesome webfont.

the component should look somewhat like this:

<Icon type="something" />

where something is the name of an icon. if something doesn't exist in font awesome, it should fall back to bug so one could visually see it's failing.

also the web-font should use SVG for the icon sets as per discussion in #3 so your css-modules setup should account for that an skip on all other formats

Part of the input fields component found here

there is a bunch of those that are usually needed:

• <Row>
• <Col size={2} offset={3}>
• <Sidebar>
• <Header> - like the page main header
• <Main> - the main section of a page
• <Footer> - the footer section

navigation menus and stuff probably should go in a separate ticket

@madrabbit Following on from over here..

as for the storybooks, yes we did ditch those in apps, but it makes the perfect sense to use them for an UI library, so, please set it up for this project.

Would there be any need for a local webpack-dev-server if we are to use storybook? So whenever we're developing components in this UI lib would our dev flow be to use storybook to see what does/doesn't work? Or should we have a kind of style guide page that lists our components for ease of development?

as a proper framework we will need a bunch of spinners, lockers and modal dialog overlays

• <Spinner /> should fit nicely into buttons and other elements. should obey the em font size
• <Locker /> is a position: absolute; left: 0; top: 0; min-height 8em; background: rgba(0,0,0,0.5) and a <Spinner /> in the middle of it. this is a block that could be thrown in to lock a specific area in a page, or the entire screen. it also probably should take children and turn them into a label next to the spinner
• modal overlay, should have the same styling as the <Locker /> but not really an element, we just need to prep some styles for the actual <Modal /> element

Part of the input fields component found here and the select input component found here. Instead of selecting just one option, multiple selected options will appear as tags

What shall our default support plan look like? I suggest we support evergreen browsers (both mobile + desktop) and probably don't go farther back than IE10 for IE.

Though, it is worth pointing out that the majority of intended projects for redbeard will be MVPs, and we should probably pay due diligence and gather up some browser support stats from past projects (no farther back than 1 year?) and see what support looked like. If there is overwhelming results for iPhone 4's and IE9, then we should at least discuss what means for redbeard UI. That discussion should have beers.

Create a buildJointSchema(props) function. It should:

• Clone existing schema if passed in via props
• Create a new schema object if props.schema is undefined
• Have props (such as min, max, required, pattern) take priority over what is in an existing schema (if there is one)

Once we have some css from Jeremy, we will need a way to split it and integrate the base stylesheet, css-reset and so on

We are going to use css modules on this project. Which is awesome. But we still need to figure out the basic needs, like typography, spacing, grids, color schemas, basic UI components, and stuff. We would be very silly trying to do this all by ourselves, so we need to pick one as a base.

As far I'm concern there are the following options (throw in new ones if you know something!):

• Bootstrap
• Foundation
• Materialize
• Skeleton

Basically we need to consider the following:

• How easy it is to deal with
• How easy it is to style later
• How much unused overhead it has

For example:

bootstrap - can be pretty boilerplaty, but provides a complete solution and very easy to style later. there are gazillions of premade themes and it was a defacto standard for a while
foundation - slightly easier to use, a lot is left to sane defaults. there is some degree of theming flying around, but nearly not as much as for bootstap
materialize - rather easy to deal with, has most of the things in, but styling is pretty much manual
skeleton - super minimalistic, it's just some sane defaults, typography and grids. so it is quite unobtrusive to the implementation, but later styling and themes will be on the developer. which depending on a case can be quite a lot.

So, that is your kick in. I'm open to hear opinions on the subject

We need to consider a few options here as well:

• glyphicons - obviously comes with bootstrap
• fontawesome - we will look like half of the internet
• material icons - okayish stylistically but my favorite when it comes to actual useage
• stroke-7 - are pretty neat and clean looking

[add your favorite icons set here]

all everything

• Input field that only allows numbers
• Demonstrated in stories
• Test case for correct props on input element
• Test case to ensure correct sub-component is used with type="number"
• Test getter/setter methods that deal with type 'number'

This can be tricky and need to be thought through. But basically there should be at least three components to it:

• generic modal dialog
• confirmation dialog
• alert dialog
• form with inputs dialog

Part of the input fields component found here

As per initial description in #4

• modal overlay, should have the same styling as the <Locker /> but not really an element, we just need to prep some styles for the actual <Modal /> element

Part of the input fields component found here

As per initial description in #4

• <Locker /> is a position: absolute; left: 0; top: 0; min-height 8em; background: rgba(0,0,0,0.5) and a <Spinner /> in the middle of it. this is a block that could be thrown in to lock a specific area in a page, or the entire screen. it also probably should take children and turn them into a label next to the spinner

We should take redbeard-ui sooner rather than later!

Also, shall we add an .npmignore file while we're here? Might be cleaner to just bundle up /dist and other relevant files, and then nothing else.

I think we should lint our CSS - http://stylelint.io/

Be great to get some consistency with CSS across the company, and what better place to start than here.

we will most definitely have some buttons as a <Button /> component. it should have the following things on them

• submit={true} to make it a submit button
• type="primary | default | danger | success | info | shallow" - to show different styles
• busy={"text" or true} - shows a spinner on the inside, and flips the text if provided

buttons should be made with the BUTTON tag and take children, example

<Button submit busy={this.props.saving}>Send</Button>

also all styling should be done in em so that they would follow the context

To be in the Input fields container found here

Basic dropdowns and menu lists (both horizontal and vertical) are a must

Jeremy needs an initial list of components that will be the library so he could start sketching them up

as we're working with JSON schemas in redbeard, we need something that will turn a model schema into a standard set of <Input /> fields that can be then embedded into a form or something else

<InputSet
  model={ {values} }
  schema={ this.props.modelSchema }
  skipFields={ [ "prop1", "prop2" ] } // <- optionally skip fields from schema
  onlyFields={ [ "prop1", 'prop2" ] } // <- optionally specify fields from schema
/>

this probably could be named better

Part of the input fields component found here

Part of the input fields component found here

we also need a generic input field component that looks something like this:

<Input
  type={ "text" | "password" | "checkbox" | "radio" | "textarea" | "select" | "multi-select" | ... }
  label="Some textual value"
  placeholder="some text"
  required= { true }
  pattern={ ".... " }
  schema={ json schema props value }
  ref={ "text-name" | e => this.smth = e }
  error="Validation error"
  />

depending on the type or schema this should generate the correct input block, along with an INPUT, SELECT or TEXTAREA field (later on SELECT will be replaced with pretty drop-downs and stuff), a label and necessary attributes.

the component itself should have the following methods exposed so it would be easier to deal with later on:

class Input extends React.Component {
   .....
   get value() {
     return this.refs.innerInput.value;
  }
  set value(value) {
    this.refs.innerInput.value = value;
  }
}

Well we need a FORM tag abstraction as well. As the first spec form should be able to abstract all the submit events and collect data from the child input fields:

<Form onSubmit={ data => this.save(data) }>
  <Input type="text" name="username" label="Username" />
  <Input type="password" name="password" label="Password" />
  <Button type="primary" submit busy={ this.props.saving }>Sign In</Button>
</Form>

We need a catchy short description for this project, for package.json, README, github and tagging on random train tunnels.

So far I've thought of... "Collection of React UI components".

So, we need the basic structure for this, that looks somewhat like so:

src/
  components/
    button.js
    input.js
    form.js
  styles/
  index.js // <- exports all publicly accessible components

test/
  compnents/
    button_test.js
    input_test.js
    form_testjs
  helper.js  // <- sets up JSX and stuff
  mocha.opts

package.json // <- has "main" : "src/index.js"

We will keep growing the structure from there. But, for now the following tools need to be set.

• basic project structure
• react tools (webpack, css modules, etc)
• testing environment with mocha, chai, enzyme and istanbul
• eslint, based on prismatik's config
• husky, with precommit & prepush tasks
• storybook with ability to look through basic usage scenarios