Giter Club home page Giter Club logo

minidocs's Introduction

minidocs

NPM version js-standard-style

build a minimalist site for your documentation

This module generates a documentation site from two simple components:

  1. A collection of markdown documents
  2. A hierarchical object specifying your table of contents

This module is intentionally simpler and more opinionated than something like Jekyll or Sphinx. Depending on what you're looking for, that might be good, because it's easier to reason about, or bad, because it's less flexible! It'll probably be most useful if your documentation already consists entirely of markdown files, and it composes well with any tools that generate markdown, for example ecosystem-docs, which pulls README files from a collection of GitHub repositories.

Sites can be built using a command-line tool, or using the library as a module with browserify. There are options for specifying a project logo, custom css, and other basic formatting. Support for themes coming soon! PRs welcome!

Here is a simple example site built with minidocs

install

command-line

Install as a command-line tool

npm install -g minidocs

library

Add to your project with

npm install --save minidocs

examples

using minidocs on the command-line

Just specify the location of your markdown files, the table of contents, the output location, and build the site

minidocs docs/ --contents contents.json --output site/

The folder site will now contain the html, js, and css for your site.

Have a images or other files you'd like to include? You can copy a directory into the build of your site with the --assets option:

minidocs docs/ --contents contents.json --output site/ --assets images

Want to change the styles? Use the --css option to include a custom stylesheet.

minidocs docs/ --contents contents.json --output site/ --css style.css

See all other cli options.

using minidocs as a JS module

Create a table of contents in a file named contents.json:

{
  "overview": {
    "about": "about.md"
  },
  "animals": {
    "furry": {
      "sheep": "sheep.md"
    },
    "pink": {
      "pig": "pig.md"
    }
  }
}

Then build the site and add it to the page with

var minidocs = require('minidocs')

var app = minidocs({
  contents: './contents.json',
  markdown: './markdown',,
  logo: './logo.svg'
})

var tree = app.start()
document.body.appendChild(tree)

This assumes you have the files about.md, sheep.md, and pig.md inside a local folder markdown.

To run this in the browser you'll need to use the minidocs transform with browserify or budo:

browserify example:

browserify index.js -t minidocs/transform > bundle.js

budo example:

budo index.js:bundle.js -P -- -t minidocs/transform

You can also add transforms to your project by adding a browserify field to the package.json file with a transform array:

"browserify": {
  "transform": [
    "minidocs/transform"
  ]
}

about the minidocs transform

Packaged with minidocs is a transform that takes care of reading the contents file, the markdown files, highlighting code in the markdown, and bundling the JS and CSS.

The minidocs transform is only necessary when using minidocs as a JS module, not when using the minidocs cli tool.

run the example

To run a full example, clone this repository, go into the folder example then call

npm install
npm start

usage

command-line

Usage:
  minidocs {sourceDir} -c {contents.json} -o {buildDir}

Options:
  * --contents, -c     JSON file that defines the table of contents
  * --output, -o       Directory for built site [site]
  * --title, -t        Project name [name of current directory]
  * --logo, -l         Project logo
  * --css, -s          Optional stylesheet
  * --assets, -a       Directory of assets to be copied to the built site
  * --initial, -i      Page to use for root url
  * --pushstate, -p    Create a 200.html file for hosting services like surge.sh
  * --basedir, -b      Base directory of the site
  * --full-html, -f    Create HTML files for all routes. Useful for GitHub Pages. [false]
  * --help, -h         Show this help message

library

var minidocs = require('minidocs')

var app = minidocs(opts)

Where opts is an object that can specify the following options

  • contents the path to a JSON file or JS module with the table of contents, required
  • markdown the path to the directory of markdown files
  • styles a stylesheet, if not required will only use base styles
  • logo relative file path to a logo file, if unspecified will not include a logo
  • initial which document to show on load, if unspecified will load the first document
  • root a DOM node to append to, if unspecified will append to document.body
  • basedir the base route of the minidocs app (useful if published as a project on github pages)

var tree = app.start(rootId?, opts)

The start method accepts the same options as choo's start method.

This generates the html tree of the application that can be added to the DOM like this:

var tree = app.start()
document.body.appendChild(tree)

var html = app.toString(route, state)

The toString method accepts the same options as choo's toString method

We use this in the command-line tool to generate the static files of the site.

deploying minidocs

surge.sh

surge.sh supports HTML5 pushstate if you have a 200.html file in your built site. You can either create that file yourself when using minidocs as a JS module, or you can build the site with the minidocs cli tool and the --pushstate option:

minidocs docs/ -c contents.json --pushstate -o site/
Deploy with the surge command

You can use the surge module to push the built site to the surge.sh service.

Install surge:

npm install --save-dev surge

Create a deploy npm script:

"scripts": {
  "deploy": "surge dist"
}

Publish your site:

npm run deploy

github pages

GitHub Pages doesn't support HTML5 pushstate, so you have two options:

1. Generate the site with the minidocs cli

Build a minidocs site with the cli and the --full-html option:

minidocs path/to/docs/dir -c contents.json -o site --full-html

This creates an HTML file for each route of the site, so that on initial page load all content is sent from the server, and once the JS is loaded the minidocs app takes over all routing.

2. Use hash routing with the JS module

To use hash routing, start the app with the { hash: true } option in the minidocs.start method:

var tree = app.start({ hash: true })
document.body.appendChild(tree)
Deploy with the gh-pages command

You can use the gh-pages module to push the built site to the gh-pages branch of your repo.

Note: if you're deploying a project at a basedir like username.github.io/project-name, you'll want to use the --basedir /project-name option

Install gh-pages:

npm install --save-dev gh-pages

Create a deploy npm script:

"scripts": {
  "deploy": "gh-pages -d dist"
}

Publish your site:

npm run deploy

license

MIT

minidocs's People

Contributors

fraserxu avatar freeman-lab avatar hbehrens avatar joehand avatar okdistribute avatar sethvincent avatar yoshuawuyts 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

minidocs's Issues

properly read & render markdown files in subdirectories

Right now only the files in the top level markdown directory are read.

It's easy to make a change that recursively reads the files by changing the filter argument passed to read-directory, but currently the name of the subdirectories are excluded from the resulting object keys.

Main questions:

  • Should the routes of the app reflect the directory structure?
  • Should there be an option that determines if the routes reflect the directory structure?
  • If routes reflect directory structure, what should happen when a markdown file is at /test/foo and a user navigates to /test/? Probably just show the first matching file?

This is somewhat related to #5, inferring the table of contents from the directory structure

Feature: Add TOC for page to Menu

@Karissa suggested it'd be nice to have a TOC for the current page in the menu (similar to Read the Docs). It'd definitely be useful but may be a pretty big feature (especially if we do all the TOC levels + collapsing).

What do y'all think of adding this feature? Maybe we could start with just the minimal TOC of h2 headers.

I did a quick prototype here and tried to add some minimal styles:

screen shot 2016-08-25 at 11 18 07

add --minify option to cli & document options for minifying the bundle when using the js api

Example:

"scripts": {
    "bundle:min": "browserify index.js -t minidocs/transform -g unassertify -g yo-yoify -g es2020 -g uglifyify -t envify -p bundle-collapser/plugin > bundle.min.js",
    "bundle": "browserify index.js -o bundle.js -t minidocs/transform",
    "start": "budo index.js:bundle.js -l -P -- -t minidocs/transform -g unassertify -g yo-yoify -g es2020 -g uglifyify -t envify -p bundle-collapser/plugin"
  },

support document specific links

It'd be nice if we could add to each document an optional link (e.g. to an external website, or to a github repo), which would then be displayed above the contents pane. Could be specified in contents.json if we support extra fields like:

{
   'about': {file: 'about.md', link: 'https://mywebsite.com'}
   'example': {file: 'example.md', link: 'https://anotherwebsite.com'}
}

But it'd be nice to keep supporting the simpler case of mapping keys to markdown files, could be supported by doing some simple type checking on the value (i.e. if string, construct an object with that string as the file).

Big Bundle Size from highlight.js

The bundle size right now is 1.4MB, 581โ€‰KB gzipped, for a fairly simple docs site (docs.dat-data.com). It looks like most of that is because all of the 175 (very obscure) highlight.js languages are included in the bundle.

Can we remove the non-common language highlights from the bundle?

Or if not, can we add an option to output a static site without the bundle? For a small static docs site, it doesn't seem like client side routing is worth such a large initial download. I'd rather just have static html.

Minidocs transform breaks CLI build

I updated to 4.0.0 and changed the transform to the minidocs transform but cannot build the site anymore.

The parse-options module is being called twice and the second time (from minidocs/transform) options.contents is no longer a path but an array.

So in parse options line 9, var contentsPath = path.resolve(options.dir, options.contents) fails.

Happy to PR but couldn't quite figure out where/why contents is changing from the path to contents array.

parse-options options:

options = { title: 'The Dat Project',
  logo: 'dat-data.png',
  contents: 
   [ { depth: 1, name: 'Introduction' },
     { depth: 2,
       name: 'Welcome to Dat',
       source: 'http://github.com/datproject/docs',
       contributors: [Object],
       key: 'welcome',
       link: '/welcome' },
    ...
   ],
  markdown: '/Users/joe/node_modules/dat-docs',
  initial: 'welcome',
  basedir: '',
  dir: '/Users/joe/node_modules/dat-docs/dist',
  routes: {}
  ...

Full error

> minidocs . -c contents.json -i welcome -o dist -l dat-data.png -t 'The Dat Project' -s styles.css --full-html

{ TypeError: Path must be a string. Received [ { depth: 1, name: 'Introduction' },
  { depth: 2,
    name: 'How Dat Works',
    key: 'how-dat-works',
    link: '/how-dat-works' },
  { depth: 1, name: 'Ecosystem' },
  { depth: 2,
    name: 'Overview',
    key: 'ecosystem',
    link: '/ecosystem' },
  { depth: 1, name: 'Specification' },
  { depth: 2,
    name: 'hyperdrive',
    key: 'hyperdrive',
    link: '/hyperdrive' },
  { depth: 2, name: 'meta.dat', key: 'meta.dat', link: '/meta.dat' },
  { depth: 1, name: 'References' },
  { depth: 2, name: 'API', key: 'api', link: '/api' },
  { depth: 2, name: 'DIY Dat', key: 'diy-dat', link: '/diy-dat' } ] while parsing file: /Users/joe/node_modules/dat-docs/dist/index.js
    at assertPath (path.js:7:11)
    at Object.resolve (path.js:1148:7)
    at module.exports (/Users/joe/node_modules/minidocs/lib/parse-options.js:8:27)
    at staticModule.minidocs (/Users/joe/node_modules/minidocs/transform.js:20:27)
    at walk (/Users/joe/node_modules/minidocs/node_modules/static-eval/index.js:89:27)
    at module.exports (/Users/joe/node_modules/minidocs/node_modules/static-eval/index.js:114:7)
    at traverse (/Users/joe/node_modules/minidocs/node_modules/static-module/index.js:256:23)
    at walk (/Users/joe/node_modules/minidocs/node_modules/static-module/index.js:224:18)
    at walk (/Users/joe/node_modules/minidocs/node_modules/falafel/index.js:49:9)
    at /Users/joe/node_modules/minidocs/node_modules/falafel/index.js:46:17
  filename: '/Users/joe/node_modules/dat-docs/dist/index.js',
  stream: {...}

Add to README a tip about images when using command line

When using the command line to build a site (https://github.com/freeman-lab/minidocs#using-minidocs-on-the-command-line), the user must make sure that any of the images used in the markdown files are copied to the site directory. If the images can not be found when running a webserver and accessing the files in the site build directory, the image will not render.

A simple fix would be to edit the README.md to remind users to take care to copy the directory containing their images to the site build directroy.

Create a minidocs transform

A minidocs transform could look like this:

  • it could live in the minidocs repo at /transform.js
  • basic usage of minidocs would be easier. users wouldn't have to install and use read-directory or myriad other transforms, they could just use minidocs/transform:
    • browserify index.js -t minidocs/transform -o bundle.js
  • it would help a lot with optimizing the build to get a smaller bundle size without making the users figure that out
  • it could handle:
    • reading, parsing, and highlighting markdown with marked & highlight.js
    • parsing the table of contents into the format the sidebar menu uses
    • inlining/bundling the css via sheetify
    • running yo-yoify for older browser support

I think @mathisonian suggested a minidocs-specific transform a while ago ๐Ÿ˜„. This morning I was like "oh right that's a good idea."

I'm looking at bundleify as inspiration for how this might work: https://github.com/bendrucker/bundleify

show contributors

It might be cool if we had an extra option for showing contributors to a project, in the style of the stack.gl site.

It'd work something like this: you specify one or more GitHub handles as an extra option, and we append a collection of small images (that link to GitHub profile pages) at the bottom of the sidebar on the left. I can put together a mock and add it to this issue.

Thoughts?

vertical height with no logo

Currently results in empty space at the bottom, we should either change the vertical height of sidebar / main display when there's no logo, or replace the logo region with the project title.

Scroll position upon page change

When using the side bar navigation, the scroll position is inherited from the current viewed page. I think it should be either the top of the page, or the last scroll location of that page.

scrolling on mobile

The mobile view is now much nicer, but scrolling the main contents seems to be broken (at least on iOS iPhone 5+6). Scrolling the menu works fine.

discussion: support yml format

Currently it supports to define the nav in a JavaScript object

var contents = {
  'overview': {
    'about': 'about.md'
  },
  'animals': {
    'furry': {
      'sheep': 'sheep.md'
    },
    'pink': {
      'pig': 'pig.md'
    }
  }
}

If it can support yml, it will be

---
  overview: 
    about: "about.md"
  animals: 
    furry: 
      sheep: "sheep.md"
    pink: 
      pig: "pig.md"

The advantage of using yml is when the navigation becomes big, it will become much easier to read and write compare to json, but the downside it's we need to include a library to parse yml file.

What do you think?

discussion: how to manage documentation between versions

Docs always document a subject. Sometimes the subject introduces breaking changes, and if there are a lot of docs it might take a while to update the docs. An option is to hold off releasing the version until the documentation has been updated, but that might stagnate releases. What would be nice is to have a way of reflecting at which version the subject is; so that the documentation can be updated gradually and transparently without ever needing to block a release.

Another problem that arises is when the documentation has been updated, but people haven't upgraded yet. They might be viewing documentation that doesn't work for their particular version. Features might be introduced in newer versions, and they run into issues. Sometimes people might not be ready to upgrade yet, and need access to older docs - which can be rough if we don't expose copies of them. It would be nice if there was a way to access these older documents - targeting specific version or otherwise.

I know all of this could definitely introduce a slew of complexity; but I think acknowledging this problem exists and exploring possible solutions would be greatly beneficial. Thanks!


edit: so tldr:

  • can we add a lil note for which version a document is intended
  • can we figure out a way to host documentation for multiple versions

Minidocs eats links to pages on the same domain not on minidocs

I'm working on https://idyll-lang.github.io/ and wanted to add a link to https://idyll-lang.github.io/idyll/scroll/. The problem is that when a user clicks the link the URL bar is updated with push state, but since that page is separate from my minidocs app it doesn't know how to load the content.

Maybe there can be a way to signify to miniocs that the link is external? I'm not sure what a good solution would be without digging too much into the minidocs code

extraneous markdown should not be fatal

right now if you have md files not listed in the TOC, it fails with cryptic message:

node_modules/minidocs/components/content.js:32
  var link = pageData.source ? el`<a class="markdown-link" href="${pageData.source}">source</a>` : ''

TypeError: Cannot read property 'source' of undefined

it should be just a warning if minidocs finds unlisted md files.

Error in finding minidocs/transform module

When running a -t minidocs/transform command, error is returned even after installing with -g or cloning the minidocs repo and starting/installing from the repo.

Steps to reproduce:

(Tried both in a windows and OS X environment running latest version of node)

  1. Run in terminal: npm install -g minidocs
  2. Follow the readme up to browserify index.js -t minidocs/transform > bundle.js

or

  1. Download/clone the minidocs repo.
  2. cd to directory of the repo.
  3. Run in terminal: npm install (works fine).
  4. Run in terminal: npm start.

Both results in returning the error:

Error: Cannot find module 'minidocs/transform'

pathnames for pages

Linking to specific docs pages will be a common need, so I'd like to add pathnames that map to the table of contents.

minidocs site for minidocs

I'd like to make a minidocs site for minidocs with a bunch of usage examples with other modules.

  • gh-pages (#8)
  • surge (#8)
  • ecosystem-docs

others?

[Discussion] very custom styles - support using external components or ?

Hey, so we wanted to get the Dat docs a bit more consistent style-wise with everything else. This ended up requiring me to fork and modify the minidocs components to get this result. We'd rather not diverge from any more work that goes on here, opening this for discussion + thoughts on how to move forward.

My fork mostly supports the example docs. I cut a few corners and there are a few hardcoded things (mainly the navigation links in header). There were a few options for how a more custom style could be supported in minidocs:

  • Change default style to use header
  • Add option to use header instead of logo/title in sidebar
  • Add option to allow custom components, essentially allowing external modules here as an option.

Change Default Style

Change the default minidocs style completely to use the header. This is mostly done in the fork, as I was using the example folder in development. There were a few hardcoded things that would need to be addressed.

Externally, this would be the smallest change in development (but a large change in style). We could probably accomplish this with a minor version update and adding a single option (for the navigation links).

Header Option

Support the default style and a style that has the header. I think this is a good middle ground that wouldn't require too much external customization. I'd lean towards this one since it wouldn't be a huge amount of work but would let both styles co-exist.

The changes I made ended up being a pretty big fork of the minidocs/components because of how sidebar styling was done previously. Reconciling the two in order to support both is definitely possible. The main task would be thinking through how to set the header option and add any navigation links in the header.

We could also do this with a minor version, adding an option to use the header styles and the navigation links.

Custom Components

Minidocs parsing and stuff is the really powerful part of this module. This option would allow for anyone to build custom styles on top of the minidocs parsing engine.

This would be pretty cool, but this option is probably the most work. We'd have to separate out the default components from the parsing stuff and add options to use an external component for styling.

See also:

pages got canonicalized on gh-pages and break links

For example, the permalink http://docs.dat-data.com/api generated from the client app, will get canonicalized as http://docs.dat-data.com/api/ when user reloads or visits the page directly. This makes the logo and potentially links within markdown broken.

show cli usage examples with surge & gh-pages in readme

This module along with surge / gh-pages makes publishing a little docs site pretty easy!

gh-pages

minidocs docs -c docs/content.json -o dist && gh-pages -d dist"

surge

minidocs docs -c docs/content.json -o dist && surge . {yourdomain}.surge.sh"

Themes

In the readme there's a mention of adding support for themes. Making an issue for it!

I'm imagining that a theme for minidocs would just be a css file.

The cli would have a --theme option:

minidocs site/ -c contents.js --theme theme.css

The js api would have an option:

var minidocs = require('minidocs')
var read = require('read-directory')

var app = minidocs({
  contents: contents,
  markdown: read.sync('./markdown', { extensions: false }),
  theme: './theme.css'
})

var tree = app.start()
document.body.appendChild(tree)

With our existing style option, which is additive, the default css is still included.

The theme option would disable most of the built-in css and replace it with the theme css.

It could be more than a css file maybe, but that would be a lot more complicated.

I'm not sure how best to specify codemirror styles in a theme. They could be defined inside the theme.css file and it could be passed to codemirror. Customizing codemirror styles might actually be a separate issue/option.

cli tool: option for generating full index files

It would be convenient if the command-line tool could generate full html files for each of the pages.

This would be particularly useful for supporting pathnames (#19) on github pages.

If we have an html file for each page, it would make supporting pathnames using html5 pushstate on github pages possible.

This is because github pages can't send a 200 request on the first request unless there's an html file at the given pathname.

This would be pretty easy to add, and would just introduce a --html option (or something like that) to the command-line that's false by default.

safari broken

the side panel doesn't work properly on safari if you click a section and then try to go to a different section

Peer [email protected] wants insert-css@^1.0.0

I was installing a repo that depends on minidocs and I got this error while npm installing

npm ERR! Linux 4.2.0-c9
npm ERR! argv "/home/ubuntu/.nvm/versions/node/v4.4.5/bin/node" "/home/ubuntu/.nvm/versions/node/v4.4.5/bin/npm" "install"
npm ERR! node v4.4.5
npm ERR! npm  v2.15.5
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package [email protected] does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants insert-css@^1.0.0

The project doesn't use sheetify, just minidocs, so I saw you are using insert-css@^0.2.0 and sheetify peer depends on insert-css@^1.0.0. So just upgrading insert-css in package.json should fix that.

external links in the sidebar / table of contents

For the Idyll documentation my config has pages for links to gitter and github, but really I just want an outbound link, e.g.

module.exports = {
  // ... other stuff 
  Publishing: {
    // normal markdown file
    "Deploying to the web": "publishing-deploying-to-the-web.md"
  },
  "Open Source": {
    // external link
    GitHub: "https://github.com/idyll-lang/idyll"
  }
}

Errors with basic example

I tried both (1) running the simple example from the readme against versions 4.2 and 4.1 on npm and (2) cloning and running examples/cli locally and got the same error in the browser both times:

Uncaught DOMException: Failed to execute 'setAttribute' on 'Element': '}' is not a valid attribute name.
    at belCreateElement (http://172.28.7.59:9966/bundle.js:1329:14)
    at http://172.28.7.59:9966/bundle.js:6731:12
    at http://172.28.7.59:9966/bundle.js:6782:45
    at module.exports (http://172.28.7.59:9966/bundle.js:160:14)
    at chooWrap (http://172.28.7.59:9966/bundle.js:4365:18)
    at emit (http://172.28.7.59:9966/bundle.js:20855:22)
    at match (http://172.28.7.59:9966/bundle.js:18401:19)
    at onReady (http://172.28.7.59:9966/bundle.js:4307:25)
    at HTMLDocument.onLoad (http://172.28.7.59:9966/bundle.js:4585:5)

I'm on node 6.9. This causes the list of pages to not appear in the sidebar:

screen shot 2017-03-31 at 1 47 38 pm

Improve bold font visibility

The bold text is not very bold:
screen shot 2016-08-05 at 12 12 26

What do y'all think about changing the bold font to clear_sans_lightregular:
screen shot 2016-08-05 at 12 13 11

Or clear_sans_mediumregular:
screen shot 2016-08-05 at 12 14 40

(Or we could include the clear_sans bold font)

mobile style improvements

Right now a minidocs site is mostly unusable on a mobile phone.

Minimal high-level changes needed to get reasonable usability when viewed on mobile device:

  • put logo at top of page
  • hide sidebar by default
  • show menu button that when touched shows the menu

Add support for customised css?

Hi, do you have any plan for supporting inject customised css? The reason is that while building a documentation for a team, there's high chance that will need to follow some sort of branding, colour schema etc.

Do you think we can add an option to the api that support custom CSS?

Usage

require('minidocs')(contents, {
  logo: 'logo.svg',
  style: 'style.css'
})

And the code

var customCss = fs.readFileSync(path.join(__dirname, opts.style))
insertcss(customCss)

Please let me know what you think and I'm happy to create a pull request for it, thanks!

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.