store

CONTRIBUTING.md

@@ -3,27 +3,29 @@
 We would love for you to contribute to topology and help make it even better than it is
 today! As a contributor, here are the guidelines we would like you to follow:
 
- - [Issues and Bugs](#issue)
- - [Feature Requests](#feature)
- - [Submission Guidelines](#submit)
- - [Coding Rules](#rules)
- - [Commit Message Guidelines](#commit)
+- [Issues and Bugs](#issue)
+- [Feature Requests](#feature)
+- [Submission Guidelines](#submit)
+- [Coding Rules](#rules)
+- [Commit Message Guidelines](#commit)
 
 ## <a name="issue"></a> Found a Bug?
+
 If you find a bug in the source code, you can help us by
 [submitting an issue](#submit-issue) to our [GitHub Repository][github]. Even better, you can
 [submit a Pull Request](#submit-pr) with a fix.
 
 ## <a name="feature"></a> Missing a Feature?
-You can *request* a new feature by [submitting an issue](#submit-issue) to our GitHub
-Repository. If you would like to *implement* a new feature, please submit an issue with
-a  for your work first, to be sure that we can use it.
+
+You can _request_ a new feature by [submitting an issue](#submit-issue) to our GitHub
+Repository. If you would like to _implement_ a new feature, please submit an issue with
+a for your work first, to be sure that we can use it.
 Please consider what kind of change it is:
 
-* For a **Major Feature**, first open an issue and outline your proposal so that it can be
-discussed. This will also allow us to better coordinate our efforts, prevent duplication of work,
-and help you to craft the change so that it is successfully accepted into the project.
-* **Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
+- For a **Major Feature**, first open an issue and outline your proposal so that it can be
+  discussed. This will also allow us to better coordinate our efforts, prevent duplication of work,
+  and help you to craft the change so that it is successfully accepted into the project.
+- **Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
 
 ## <a name="submit"></a> Submission Guidelines
 
@@ -43,43 +45,45 @@ We will be insisting on a minimal reproduce scenario in order to save maintainer
 
 Unfortunately we are not able to investigate / fix bugs without a minimal reproduction, so if we don't hear back from you we are going to close an issue that don't have enough info to be reproduced.
 
-You can file new issues by filling out our [new issue form](https://github.com/le5le-com/topology/issues/new).
-
+You can file new issues by filling out our [new issue form](https://github.com/le5le-com/topology.js/issues/new).
 
 ### <a name="submit-pr"></a> Submitting a Pull Request (PR)
+
 Before you submit your Pull Request (PR) consider the following guidelines:
 
-* Search [GitHub](https://github.com/le5le-com/topology/pulls) for an open or closed PR
+- Search [GitHub](https://github.com/le5le-com/topology.js/pulls) for an open or closed PR
   that relates to your submission. You don't want to duplicate effort.
-* Make your changes in a new git branch:
+- Make your changes in a new git branch:
 
-     ```shell
-     git checkout -b my-fix-branch master
-     ```
+  ```shell
+  git checkout -b my-fix-branch master
+  ```
 
-* Create your patch, **including appropriate test cases**.
-* Follow our [Coding Rules](#rules).
-* Run the full topology test suite <!-- , as described in the [developer documentation][dev-doc] -->, and ensure that all tests pass.
-* Commit your changes using a descriptive commit message that follows our
+- Create your patch, **including appropriate test cases**.
+- Follow our [Coding Rules](#rules).
+- Run the full topology test suite <!-- , as described in the [developer documentation][dev-doc] -->, and ensure that all tests pass.
+- Commit your changes using a descriptive commit message that follows our
   [commit message conventions](#commit). Adherence to these conventions
   is necessary because release notes are automatically generated from these messages.
 
-     ```shell
-     git commit -a
-     ```
+  ```shell
+  git commit -a
+  ```
+
   Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files.
 
-* Push your branch to GitHub:
+- Push your branch to GitHub:
 
-    ```shell
-    git push origin my-fix-branch
-    ```
+  ```shell
+  git push origin my-fix-branch
+  ```
 
-* In GitHub, send a pull request to `topology:master`.
-* If we suggest changes then:
-  * Make the required updates.
-  * Re-run the topology test suites to ensure tests are still passing.
-  * Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
+- In GitHub, send a pull request to `topology:master`.
+- If we suggest changes then:
+
+  - Make the required updates.
+  - Re-run the topology test suites to ensure tests are still passing.
+  - Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
 
     ```shell
     git rebase master -i
@@ -93,44 +97,46 @@ That's it! Thank you for your contribution!
 After your pull request is merged, you can safely delete your branch and pull the changes
 from the main (upstream) repository:
 
-* Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
+- Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
 
-    ```shell
-    git push origin --delete my-fix-branch
-    ```
+  ```shell
+  git push origin --delete my-fix-branch
+  ```
 
-* Check out the master branch:
+- Check out the master branch:
 
-    ```shell
-    git checkout master -f
-    ```
+  ```shell
+  git checkout master -f
+  ```
 
-* Delete the local branch:
+- Delete the local branch:
 
-    ```shell
-    git branch -D my-fix-branch
-    ```
+  ```shell
+  git branch -D my-fix-branch
+  ```
 
-* Update your master with the latest upstream version:
+- Update your master with the latest upstream version:
 
-    ```shell
-    git pull --ff upstream master
-    ```
+  ```shell
+  git pull --ff upstream master
+  ```
 
 ## <a name="rules"></a> Coding Rules
+
 To ensure consistency throughout the source code, keep these rules in mind as you are working:
 
-* All features or bug fixes **must be tested** by one or more specs (unit-tests).
-* All public API methods **must be documented**.
+- All features or bug fixes **must be tested** by one or more specs (unit-tests).
+- All public API methods **must be documented**.
 
 ## <a name="commit"></a> Commit Message Guidelines
 
-We have very precise rules over how our git commit messages can be formatted.  This leads to **more
-readable messages** that are easy to follow when looking through the **project history**.  But also,
+We have very precise rules over how our git commit messages can be formatted. This leads to **more
+readable messages** that are easy to follow when looking through the **project history**. But also,
 we use the git commit messages to **generate the topology change log**.
 
 ### Commit Message Format
-Each commit message consists of a **header**, a **body** and a **footer**.  The header has a special
+
+Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
 format that includes a **type**, a **scope** and a **subject**:
 
 ```
@@ -148,53 +154,58 @@ to read on GitHub as well as in various git tools.
 
 Footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
 
-Samples: (even more [samples](https://github.com/le5le-com/topology/commits/master))
+Samples: (even more [samples](https://github.com/le5le-com/topology.js/commits/master))
 
 ```
 docs(changelog): update change log to beta.5
 ```
+
 ```
 fix(release): need to depend on latest rxjs and zone.js
 
 The version in our package.json gets copied to the one we publish, and users need the latest of these.
 ```
 
 ### Revert
+
 If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
 
 ### Type
+
 Must be one of the following:
 
-* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
-* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
-* **docs**: Documentation only changes
-* **feat**: A new feature
-* **fix**: A bug fix
-* **perf**: A code change that improves performance
-* **refactor**: A code change that neither fixes a bug nor adds a feature
-* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
-* **test**: Adding missing tests or correcting existing tests
+- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+- **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+- **docs**: Documentation only changes
+- **feat**: A new feature
+- **fix**: A bug fix
+- **perf**: A code change that improves performance
+- **refactor**: A code change that neither fixes a bug nor adds a feature
+- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- **test**: Adding missing tests or correcting existing tests
 
 ### Subject
+
 The subject contains succinct description of the change:
 
-* use the imperative, present tense: "change" not "changed" nor "changes"
-* don't capitalize first letter
-* no dot (.) at the end
+- use the imperative, present tense: "change" not "changed" nor "changes"
+- don't capitalize first letter
+- no dot (.) at the end
 
 ### Body
+
 Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
 The body should include the motivation for the change and contrast this with previous behavior.
 
 ### Footer
+
 The footer should contain any information about **Breaking Changes** and is also the place to
 reference GitHub issues that this commit **Closes**.
 
 **Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
 
 A detailed explanation can be found in this [document][commit-message-format].
 
-
 [commit-message-format]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
 [github]: https://github.com/le5le-com/topology
 [plunker]: http://plnkr.co/edit

README.CN.md

@@ -1,8 +1,8 @@
 [English](./README.md) | 简体中文
 
-# Le5le-topology
+# Topology
 
-Le5le-topology 是一个可视化在线绘图工具，使用 Canvas + Typescript。支持 topology, UML、微服务架构、动态流量、SCADA 场景等。
+Topology 是一个集动态交互、丰富展示、数据管理等一体的全功能可视化引擎，为物联网、工业互联网、电力能源、水利工程、智慧农业、智慧医疗、智慧城市等智能可视化场景而生。
 
 # 为什么使用
 

README.md

@@ -1,8 +1,8 @@
 English | [简体中文](./README.CN.md)
 
-# Le5le-topology v1
+# Topology
 
-Le5le-topology is a diagram visualization framework uses canvas and typescript. Developers are able to build diagram (topology, UML), micro-services architecture, SCADA and so on.
+Topology is a diagram visualization framework uses canvas and typescript. Developers are able to build topology, UML,diagram, architecture, SCADA and so on.
 
 # Why
 

lerna.json

@@ -1,8 +1,14 @@
 {
-  "packages": ["packages/*", "bundle"],
+  "packages": [
+    "packages/*",
+    "bundle"
+  ],
   "command": {
     "publish": {
-      "ignoreChanges": ["ignored-file", "*.md"]
+      "ignoreChanges": [
+        "ignored-file",
+        "*.md"
+      ]
     }
   },
   "npmClient": "yarn",
@@ -11,5 +17,5 @@
     "access": "public",
     "directory": "/dist"
   },
-  "version": "0.2.24"
+  "version": "1.0.0"
 }

package.json

@@ -1,6 +1,6 @@
 {
   "name": "topology",
-  "version": "0.3.4",
+  "version": "1.0.0",
   "private": true,
   "workspaces": [
     "packages/*",
@@ -22,4 +22,4 @@
     "tslint": "latest",
     "typescript": "latest"
   }
-}
+}

packages/core/README.md

@@ -1,10 +1,6 @@
 # core
 
-The topology core.
-
-# store
-
-Store provides a way to pass data through snapshot/subcribe/unsubscribe .
+The core of topology.
 
 # How to Contribute
 

packages/core/src/action/action.ts

@@ -0,0 +1,20 @@
+
+
+export interface Action {
+  do?: string;
+  url?: string;
+  _blank?: string;
+  tag?: string;
+  fn?: string;
+  params?: any;
+}
+
+export interface Where {
+  key?: string;
+  comparison?: string;
+  value?: any;
+  fn?: string;
+  actions?: Action[];
+}
+
+const eventFns: string[] = ['link', 'doStartAnimate', 'doFn', 'doWindowFn', '', 'doPauseAnimate', 'doStopAnimate', 'doEmit'];

packages/core/src/action/index.ts

@@ -0,0 +1,2 @@
+
+export * from './action';

packages/core/src/core.ts

@@ -1,12 +1,36 @@
-import pkg from '../package.json';
-import { options } from './options';
-import { useStore } from './store';
+import { EventType, Handler } from 'mitt';
+import { Options } from './options';
+import { TopologyData, TopologyStore, useStore } from './store';
 import { s8 } from './utils';
 
+declare const window: any;
+
 export class Topology {
-  version: string = pkg.version;
-  id = s8();
-  store: any = useStore(this.id);
-  options = options;
-  parentElem: HTMLElement;
+  store: TopologyStore;
+
+  constructor(parent: string | HTMLElement, opts: Options = {}) {
+    this.store = useStore(s8());
+
+    if (window) {
+      window.topology = this;
+    }
+  }
+
+  open(data?: TopologyData) {
+    if (data && data.mqttOptions && !data.mqttOptions.customClientId) {
+      data.mqttOptions.clientId = s8();
+    }
+
+    this.store.emitter.emit('opened');
+  }
+
+  on(eventType: EventType, handler: Handler) {
+    this.store.emitter.on(eventType, handler);
+    return this;
+  }
+
+  off(eventType: EventType, handler: Handler) {
+    this.store.emitter.off(eventType, handler);
+    return this;
+  }
 }