Giter Club home page Giter Club logo

lit-mobx's Introduction

Known Vulnerabilities

lit-mobx

Mixin and base class that allow easy usage of mobx observables with lit.

The mixin implementation is based heavily on the work of Alexander Weiss in his mobx-lit-element implementation. This has been rewritten to support multiple forms of usage (mixin, or base class) as well as to be based on typescript to get type definitions.

Installation

As a dependency:

npm install --save @adobe/lit-mobx lit mobx

LitElement 2.0 Usage

This library has been updated to the latest version of Lit which we highly recommend you update to. However if you wish to continue using LitMobx with LitElement 2.0 then install the 1.0 major version:

npm install --save @adobe/lit-mobx@^1.0.0

We will backport any security patches (though don't expect there to be any) in this major version as necessary.

Demo

npm install
npm run demo

Usage

See the JavaScript and TypeScript example projects on StackBlitz. See this example for a demonstration of usage with Mobx v6 in Typescript without the use of decorators.

import { html, TemplateResult } from 'lit';
import { customElement, LitElement } from 'lit/decorators.js';
import { observable, action } from 'mobx';
import { MobxLitElement } from '@adobe/lit-mobx';

// create a mobx observable
class Counter {
    @observable
    public count = 0;

    @action
    public increment() {
        this.count++;
    }
}

// create instance that can be shared across components
const counter = new Counter();

// create a new custom element, and use the base MobxLitElement class
// alternatively you can use the MobxReactionUpdate mixin, e.g. `class MyElement extends MobxReactionUpdate(LitElement)`
@customElement('my-element')
export class MyElement extends MobxLitElement {
    private counter = counter;

    // any observables accessed in the render method will now trigger an update
    public render(): TemplateResult {
        return html`
            Count is ${this.counter.count}
            <br />
            <button @click=${this.incrementCount}>Add</button>
        `;
    }

    private incrementCount() {
        this.counter.increment();
    }
}

For further examples see the demo folder.

NOTE: observables are only hooked for updating the render function if those observables are directly used within the render function. The implementation of this library is such that we essential wrap the render function in an autorun block to hook these observables for re-running render. If you wish to response to an observable property to calculate some other result that then itself is used in the render function, then you need to use the regular MobX methods for observability in a property changed callback or some other lifecycle function to setup that observation and the write to a property in your component that is appropriately decorated to drive Lit's regular update cycle.

Custom Reaction

In some rare cases applications may need to have multiple different major versions of Mobx within a single app. This can lead to issues where the version of mobx used in various places needs to be specifically imported from aliased versions of mobx, e.g. aliasing mobx 6.x to mobx6.

To help support these cases lit-mobx provides the custom implementation of the MobxReactionUpdate mixin, MobxReactionUpdateCustom, that supports taking the Reaction constructor as a second argument. This allows the user to define which version of mobx to pass, and ensures that no side effects are caused by lit-mobx importing mobx directly.

Example usage:

import { MobxReactionUpdateCustom } from '@adobe/lit-mobx/lib/mixin-custom.js';

// import your specific mobx version
import { Reaction } from 'mobx6';

// and pass it to the mixin to create your own mobx lit element base class
class Mobx6LitElement extends MobxReactionUpdateCustom(LitElement, Reaction) {}

Contributing

Contributions are welcomed! Read the Contributing Guide for more information.

Licensing

This project is licensed under the Apache V2 License. See LICENSE for more information.

lit-mobx's People

Contributors

anoblet avatar artur- avatar benjamind avatar dependabot[bot] avatar greenkeeper[bot] avatar sidhyatikku avatar westbrook 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

lit-mobx's Issues

Initial code review?

Would you like to make a PR of the current code against an empty branch in order to do a first code review? That might be easier than opening issues for each question / comment.

Lit 2 version

Please create a version 2.0.0(.pre1?) that uses Lit 2 (currently 2.0.0.pre1)

Add release tags to make it easier to see changes between releases

Would it be possible to add release tags on this github repo? It would make it a lot easier to see a diff of what has been changed between releases. At the moment is can be a bit confusing trying to figure out what was added in a new release.

I believe adding releases also allows dependabot to provide a changelog for updates, which is also nice πŸ˜ƒ

Class instance should be referred to as a singleton

Documentation does not state that instances of Counter need to be the same. Assigning a property with new Counter() will not synchronize components. Suggested edit:

// counter.ts
export const counter = new Counter();
// component1.ts
import { counter } from "./counter"
class MyElement1 extends LitElement {
  private counter = counter
} 
// component2.ts
import { counter } from "./counter"
class MyElement2 extends LitElement {
  private counter = counter
} 

Array of Objects don't request an update

Expected Behaviour

ComponentOne should rerender when todo array changed.

Actual Behaviour

Changing the todo array in store class does not request a rerender in lit

Reproduce Scenario (including but not limited to)

https://codesandbox.io/s/brave-panini-ozg2f?file=/src/component-one.ts

Steps to Reproduce

Switch from "second" page to "home" page and back again

Or add ${testString} after ${todoListTemplate} in ComponentOne render return statement.

Platform and Version

Node 14.16.0
adobe/lit-mobx 1.0.1
lit 1.01
mobx 6.3.2

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

An in-range update of mobx is breaking the build 🚨

The devDependency mobx was updated from 5.14.0 to 5.14.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

mobx is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ ci/circleci: build: Your tests failed on CircleCI (Details).
  • ❌ build: * build - Failed

Commits

The new version differs by 47 commits.

  • 5b15106 Updated bugsnag URL
  • 9919f89 Fix error when interception is removed in intercept (#1950) (#2157)
  • 90c7466 fix a broken link (#2154)
  • 4d22593 Another attempt at fixing getting-started
  • c88be97 restored getting-started
  • b3ba479 fix for 2135 (#2136)
  • 92cc3e8 Merge pull request #2151 from mobxjs/shallow-comparer
  • 9005817 update changelog
  • fc70ee3 add shallow comparer
  • 0502539 Docs: Fix title of @observable page (#2149)
  • eae6d5b chore: updated sponsor section
  • 8d653d1 Remove obsolete donation info (#2144)
  • 2b6f301 Prettier docs (#2143)
  • 2fe7ed1 Fixed a typo in the OrderLine example (#2141)
  • a480b9c Fix dead links in docs about Action (#2138)

There are 47 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @open-wc/testing-karma is breaking the build 🚨

The devDependency @open-wc/testing-karma was updated from 3.2.17 to 3.2.18.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@open-wc/testing-karma is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ ci/circleci: build: Your tests failed on CircleCI (Details).
  • ❌ build: * build - Failed

Commits

The new version differs by 3 commits.

  • 87fcf81 chore: release new versions
  • 6c04580 fix(codelabs): add read property to newsapp render
  • 5843b82 fix(karma-esm): add close body tag when injecting code to import tests

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Investigate more optimal approach to avoid closure creation in update

@justinfagnani pointed out in this comment that we are creating a new closure on each update in order to update the tracked function in the Reaction. This is less than optimal but is currently the only approach while we depend upon the Reaction class implementation.

We should investigate using lower level functions from mobx to more tightly control our update tracking. We could for instance call trackDerivedFunction directly and not use the Reaction class at all, this may let us come up with a more optimal solution that avoids the closure creation on every update.

updated not called if observable not used in render

Expected Behaviour

Observables should trigger updated() when extending MobxLitElement

Actual Behaviour

Observables only trigger an update if used within the render callback

Platform and Version

  • @adobe/lit-mobx: 2.0.0
  • mobx: 6.6.1
  • lit: 2.2.8

Sample Code that illustrates the problem

This is not reactive to observable/store updates

export class Element extends MobxLitElement {
   private store = store;

  updated() {
    console.log(this.store)
  }
}

This is reactive

export class Element extends MobxLitElement {
   private store = store;

  render() {
    html`<span>${this.store}</span>`
  }
}

An in-range update of es-dev-server is breaking the build 🚨


🚨 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! πŸ’œ πŸššπŸ’¨ πŸ’š

Find out how to migrate to Snyk at greenkeeper.io


The devDependency es-dev-server was updated from 1.47.0 to 1.48.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

es-dev-server is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ ci/circleci: build_and_test: Your tests failed on CircleCI (Details).
  • ❌ build: * build_and_test - Failed

Commits

The new version differs by 37 commits.

  • 26e9a35 chore: release new versions
  • ec1698d chore: fix lockfile
  • a2fad5f chore: add missing dependency
  • 88cadaf chore: release new versions
  • 81b0096 fix(rollup-plugin-html): typo
  • 179b299 feat(es-dev-server): move to typescript
  • 7af8329 chore: release new versions
  • 6838fc7 fix(eslint-config): fixes open-wc/open-wc#1602
  • 153b40f chore: update typescript version
  • 017deee docs(testing-karma): improve docs
  • ca2dcb0 docs(karma-esm): improve docs
  • 3878a97 docs(es-dev-server): improve docs
  • b9d5b88 chore: release new versions
  • 54c7ddf chore(storybook-addon-markdown-docs): remove unused dependency
  • b106e9e chore(demoing-storybook): avoid dependency on @storybook/addon-docs

There are 37 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of es-dev-server is breaking the build 🚨

The devDependency es-dev-server was updated from 1.23.1 to 1.24.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

es-dev-server is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ ci/circleci: build: Your tests failed on CircleCI (Details).
  • ❌ build: * build - Failed

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Batch updates and lit-mobx

I just read an article:
https://dev.to/open-wc/litelement-a-deepdive-into-batched-updates-3hh
that details how LitElement avoids multiple calls to requestUpdate() for any given block of code.

Thanks to that clever trick, a block of code that updates several observables of the litElement will only trigger
the requestUpdate() once.

Does lit-mobx implement something similar? So when a block of code updates several values of my store data, that should all trigger a requestUpdate(), only one requestUpdate() will be launched (as explained in the article).

Lit-Mobx and partial rerendering

Hi everyone.
That's not a bug report.
But more a question.
[May be StackOverflow is better suited for that.
I will elaborate there, if needed.]
My question is about partial rerendering.
For example when a component's render() function
iterates over an observable array to build (let's say) <tr>
of a table.
What if I push a new item inside that array? Or splice a new item?
Will the whole table be rerendered?
Or will only one <tr> element be created and inserted
at the correct location in the existing table?

Thanks for your help.

PS: a similar question is when you sort the array.
Is there a way for <tr> to mimic that sort in the UI without rerendering?

Upgrade to Lit 3

With the release of Lit 3, coud we please also update the mobx lib in order to use it?

image

Thank you

ESM support for SSR etc.

Hello!

#166 was marked as completed, IDK why.

import { MobxReactionUpdate } from '@adobe/lit-mobx';
         ^

SyntaxError: The requested module '@adobe/lit-mobx' does not provide an export named 'MobxReactionUpdate'

Fix, in package.json:

"type":"module",

Lit SSR needs that.

Thanks :)

Mobx6 example does not work with Node 15 / npm 7.3

With the given package.json:

{
  "name": "typescript",
  "version": "0.0.0",
  "private": true,
  "dependencies": {
    "@adobe/lit-mobx": "^0.0.4",
    "lit-element": "^2.3.1",
    "mobx": "^6.0.0"
  }
}

You get an error on

npm install
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/mobx
npm ERR!   mobx@"^6.0.0" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer mobx@"^5.0.0" from @adobe/[email protected]
npm ERR! node_modules/@adobe/lit-mobx
npm ERR!   @adobe/lit-mobx@"^0.0.4" from the root project
npm ERR! 

This is because npm 7 changed how peer dependencies are handled.

An in-range update of @open-wc/testing-karma is breaking the build 🚨


☝️ Important announcement: Greenkeeper will be saying goodbye πŸ‘‹ and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io


The devDependency @open-wc/testing-karma was updated from 3.3.4 to 3.3.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@open-wc/testing-karma is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ ci/circleci: build_and_test: Your tests failed on CircleCI (Details).
  • ❌ build: * build_and_test - Failed

Commits

The new version differs by 4 commits.

  • 277729c chore: release new versions
  • 31a682b feat(es-dev-server): auto compat for browsers without stage4 features
  • da8b4c0 chore: release new versions
  • ce8c833 feat(testing-helpers): support fixture cleanup in tdd style tests with 'teardown' (#1410)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Move to v1.0.0

I'm not sure exactly when to bump this up to a 1.0.0 release. I don't actually intend to change the interface here at all, and I don't think there's much more to be done in terms of optimization internally.

I expect the next major changes will come with MobX 6, and future major version of lit-element.

Should we just push to 1.0? Is there any benefit other than for people to feel more comfortable using a v1 project in production?

An in-range update of @open-wc/testing-karma is breaking the build 🚨


🚨 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! πŸ’œ πŸššπŸ’¨ πŸ’š

Find out how to migrate to Snyk at greenkeeper.io


The devDependency @open-wc/testing-karma was updated from 3.3.17 to 3.3.19.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@open-wc/testing-karma is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ ci/circleci: build_and_test: Your tests failed on CircleCI (Details).
  • ❌ build: * build_and_test - Failed

Commits

The new version differs by 31 commits.

  • 26e9a35 chore: release new versions
  • ec1698d chore: fix lockfile
  • a2fad5f chore: add missing dependency
  • 88cadaf chore: release new versions
  • 81b0096 fix(rollup-plugin-html): typo
  • 179b299 feat(es-dev-server): move to typescript
  • 7af8329 chore: release new versions
  • 6838fc7 fix(eslint-config): fixes open-wc/open-wc#1602
  • 153b40f chore: update typescript version
  • 017deee docs(testing-karma): improve docs
  • ca2dcb0 docs(karma-esm): improve docs
  • 3878a97 docs(es-dev-server): improve docs
  • b9d5b88 chore: release new versions
  • 54c7ddf chore(storybook-addon-markdown-docs): remove unused dependency
  • b106e9e chore(demoing-storybook): avoid dependency on @storybook/addon-docs

There are 31 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Updates to observables in `firstUpdated` not working

I haven't had a chance to dig into this too much, but I'm noticing that setting an observable that the render method uses in firstUpdated doesn't trigger a rerender. Setting a LitElement property does, as expected. Here's a simple example of what I mean:

// Doesn't work - render isn't called again
class Component extends MobxLitElement {
  @observable test = 1;

  firstUpdated() {
    this.test = 2;
  }

  render() {
    return html`<h1>${this.test}</h1>`;
  }
}
// Works as expected
class Component extends MobxLitElement {
  @property({type: Number}) test = 1;

  firstUpdated() {
    this.test = 2;
  }

  render() {
    return html`<h1>${this.test}</h1>`;
  }
}

I'll try poking around in the source a bit more to learn a bit about what's going on under the hood, but I wanted to open the issue first.

An in-range update of @open-wc/testing is breaking the build 🚨


☝️ Important announcement: Greenkeeper will be saying goodbye πŸ‘‹ and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io


The devDependency @open-wc/testing was updated from 2.5.4 to 2.5.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@open-wc/testing is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ ci/circleci: build_and_test: Your tests failed on CircleCI (Details).
  • ❌ build: * build_and_test - Failed

Commits

The new version differs by 84 commits.

  • 781e6a6 chore: release new versions
  • 21542aa chore: update lockfile
  • 796223f chore: release new versions
  • 8740d22 fix(demoing-storybook): filter incorrect imports
  • 3741c53 chore: release new versions
  • 5547ebc feat: add Markdown with JavaScript (mdjs)
  • f58e5d4 chore: release new versions
  • fd1b36b chore(polyfills-loader): update snapshots
  • ad9a0d5 chore: formatting
  • 23428e3 feat(polyfills-loader): add preload links
  • 39cc2db feat(rollup-plugin-polyfills-loader): first release
  • 73a69d6 feat(rollup-plugin-html): use named child plugins when using addOutput
  • e42c1ae feat(rollup-plugin-html): other plugins can inject transform functions
  • f4c239d chore: release new versions
  • 2acadc9 chore: fix linting in scaffolded project, and typos

There are 84 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Directly calling update() is probably dangerous

In UpdatingElement this.update() is called by performUpdate which does error handling for exceptions thrown in update(), ensures that the updating state of the element is correct, and that updated(), firstUpdated() are called correctly and that updateComplete resolves (well, that's done by _enqueueUpdate()).

I think that using a mobx Reaction is probably the right way to go. Then you can call this.requestUpdate() when mobx detects a change and all the right bookkeeping will be done.

To test this out I would add tests like throwing in update() making sure that updateComplete rejects, and that a subsequent update() actually works. I'd also test that updated() and firstUpdated() are called after mobx-triggered updates.

Demo isn't working, state change not causing a re-render

Expected Behaviour

After a lot of troubleshooting and attempting to use this package in my own project I couldn't seem to get the component to re-render when the store values are updated. I decided to go back to basics and try the demo code in the README to see if I was missing something simple but I can't even seem to get the sample to work. 😞 Am I missing something here?

Actual Behaviour

The component is mounting but it isn't updating state at all when the increment function is called

Reproduce Scenario

I created a stackblitz with a reproducible example

ESM Module type is missing in package.json

While trying to test our components with mocha. We are experiencing issues with the library. Giving this error:

import { MobxLitElement } from "@adobe/lit-mobx";
         ^^^^^^^^^^^^^^
SyntaxError: Named export 'MobxLitElement' not found. The requested module '@adobe/lit-mobx' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from '@adobe/lit-mobx';
const { MobxLitElement } = pkg;

Now if we add "type": "module" to packge.json file of the @adobe/lit-mobx error goes away.

Is it possible that this is missing from the lib ? Or to add and *.mjs export ?

AsyncDirectives prevent mobx observables retriggering update

Expected Behaviour

Using async directives should 'just work' with the rendering component updating whenever an observable inside of the async directive is updated. The async directive of course should do what it always does.

Actual Behaviour

Mobx observables are not tracked within the callbacks of renders invoked by async directives like when and until.

Couple of possible approaches to fixing/workaround this:

  • Wrap all async directive render functions with helper functions to track the invocations and re-render the hosting component
  • Never use mobx observables directly in async directive render functions and instead always pass down the observable to a MobxLitElement that itself handles the re-render.
  • Extend Lits ReactiveElement with new hooks that are driven by AsyncDirective calls to setValue within their render tree. This is a much bigger change at the core of the library and would likely need updates to the AsyncDirective API.

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.