Initiate the website with Docusaurus v3.
Setup the site and includes the content that was already available in
the `docs` package.
The currently implementation mainly uses the default theme available
when using the Docusaurus scaffolding. It was initiated with:
`npx create-docusaurus@3.0.0 my-website classic`
Providing these resources simplify the `maxGraph` integration.
Use the default CSS in ts-example to illustrate how to override defaults
Initiate a documentation to start guiding users.
ts-example
- improve the position of the ellipse labels
- introduce a shared style for ellipse vertices
- bump vite from 4.3.9 to 4.4.2
- work when not deployed in the "root" context of the site
README
- improve the position of the ellipse label
- display rounded orthogonal edge
- fix the style configuration to match the rendering shown in the gif
The methods defined in the `EdgeMixin` type were not documented.
The signature of the `insertEdge` method was using a spread `any`
parameter, so it provided no guidance nor guard.
Instead, the type now declares the various form of the methods with the
right signature.
The methods defined in the `VertexMixin` type were not documented.
The signature of the `insertVertex` method was using a spread `any`
parameter, so it provided no guidance nor guard.
Instead, the type now declares the various form of the methods with the
right signature.
Also improve the main README
- improve the paragraph about how to build the npm package locally
- use the "application" wording instead "project" when required
- highlight mxGraph and maxGraph
Clarify some git operations.
Also
- move an image to the packages/docs for future reuse in the
documentation.
- don't run the GitHub "build" workflow when the docs package or some
markdown files change.
Move everything from the README to the dedicated migration doc.
Clarify the existing content.
Co-authored-by: Souchet Céline <4921914+csouchet@users.noreply.github.com>
Remove the `StyleMap` class. It is not used anymore since the
introduction of the `CellStateStyle` interface.
Changes in `CellStateStyle`
- remove `defaultEdge` and `defaultVertex` that have been introduced by
mistake. They have never been used.
- rename `autosize` into `autoSize` for naming consistency. All
properties use camelCase.
- change types from "number" to "boolean" + fix default management in
the Shape classes
- `backgroundOutline`
- `absoluteArcSize`
Other `CellStateStyle` changes: remove a property in favor of another
property
The following properties were introduced by mistake while removing
mxConstants.STYLE_* references in
707605cedd (2021-05-02). Their counterpart
was used in `mxGraph` and is used in all
`maxGraph` examples
- `backgroundColor` in favor of `labelBackgroundColor`. The
`STYLE_LABEL_BACKGROUNDCOLOR` constant was replaced by
'backgroundColor' instead of 'labelBackgroundColor'
- `loop` in favor of `loopStyle`. The `STYLE_LOOP` constant was replaced
by 'loop' instead of 'loopStyle'
Other types that changed
- `CellStateStyle`: better type guidance for the `indicatorShape`
property
- `CanvasState`: order properties alphabetically + add JSDoc on some
properties
- Rename `ArrowType` into `ArrowValue` for consistency with other types
(they all end with the 'Value' post-fix)
Documentation update
- CHANGELOG.md: mention the breaking changes
- Initiate a specific document to help migration from mxGraph: start by
adding the changes on style
--------------------------------------------------------------------------------
**BREAKING CHANGES**: some `CellStateStyle` properties and types have
been removed/renamed.
Update the project status.
npm package availability:
- add a badge to display the latest version available in the npm
registry.
- explain how to install maxGraph in applications.
The former mxGraph tags have been removed. List them in the changelog
for history.
Also update the project status in the README as there is no more
blocking issue for a first release.
We use a recent TypeScript version to build maxGraph but applications
that integrates it may be forced to use old TypeScript versions.
We never explain what is the minimum TypeScript version requires to use
`maxGraph`. The changes proposed here are a first step to make this
information available.
It is only informative for now (mentioned in the README) and the minimum
TypeScript version is tested in the `ts-support` package (part of the
'build' GitHub workflow).
- Create a NOTICE file. It references the list of contributors that re-licensed their commits to Apache License, Version 2.0.
- So we can restore the Apache-2.0 license.
- Also update the README and the Pull Request template as there is no more warning about the license.
Root and all package.json files
- Fix license, version and authors
- Remove the non-relevant .npmignore file at the project. It was designed for mxgraph, the whole directory structure
changed, and we don't plan to publish the root package
`core` package
- Generate type definition and javascript files for ESM output
- dedicated folder for `esm` and `types` in the `dist` folder to clearly separate concerns
- exported in the package.json
- Add npm script for `npm pack` configuration
- Drop the `postinstall` npm script that built the `core` bundle. It would have been run when the package is installed
in dependent projects at dependencies install. And it would have failed as it tries to build the project from TypeScript
sources that are not available in the npm package.
fix: ConstraintHandler now loads image as everywhere else in the code using `Client.imageBasePath`
Using import doesn't work as the image is not available in the npm package. It generated error like this in ViteJS
project:
Failed to resolve import "../../../images/point.gif" from "../core/dist/esm/view/handler/ConstraintHandler.js". Does the file exist?
This gif import had been introduced to make `Anchors.stories.js` retrieve the gif file. Configuring `imageBasePath` as
already done in other stories fixes the issue.
Don't export EditorCodec and StylesheetCodec as they generate errors.
This is a temporary solution to avoid error in dependent project (at least, with ViteJS projects).
The README is the main entry point of the lib. It should provide the main information about the project and should attract potential users.
Previously, it was a mix of technical information and outdated sentences about the good old mxGraph.
This is a first attempt to improve things. In short
- First present what the lib does and the project status.
- Then, provide a code example and a gif to let potential users see the rendering at a glance.
- Remove inaccurate content and refresh the project history.
Thomas Bouffard
Tim Nelson
Amine B. Hassouna
Junsik Shim
Jon Gadsden
David Benson
Colin Claverie
David Benson
Marc Laporte