I'm making a toy project to get the hang of this library, but can't seem to be able to build it with rollup.
I've tried several approaches, but none of them is working: I keep ending up with either 'CanvasWidget' is not exported by node_modules\storm-react-diagrams\src\main.js or 'default' is not exported by node_modules\storm-react-diagrams\src\main.js. This happens regardless of whether I specify namedExports for rollup's commonJS plugin.
For reference, my rollup config is mostly derived from the one available here
Secondary question: would you be interested in PRs that migrate the codebase to ES6 modules? If so, how would you propose to best handle it?
Hi there, so yeah I wrote this little library a while ago to solve some a problem I was having, and then it kind of started picking up traction. Ive got plans to actually port the entire thing to typescript and then also vastly improve it etc.. Typescript compiles down to ECMA 5 and ECMA 6 and its much better suited for complex javascript development, which is where I think this library is going to head eventually.
I haven't used rollup before so I'm not sure how that works or what it does, but it definitely works with webpack/webpack dev server. Some guys here have forked the library and changed/updated some of the imports as well. Im interested in pull requests that add to the core, not requests that change the syntax e.g..Someone mentioned porting to JSX, which I think is a bad idea.
I also have a few architectural changes that I'm going to be making shortly to vastly improve the mechanics of the system, which will allow new things like multiple selections etc..
Well, it just so happens your library is pretty much _exactly_ what I was looking for, for a while :D
I almost started rolling my own, but I've decided to first post a question on reddit, and your lib came up.
I saw your thoughts on JSX and, while personally I'm not as averse to it, I see and respect your points. So would you consider changing the imports to ES6-ish an unwarranted syntax change, or adding to the core?
Or, more to the point and considering your mention of moving to Typescript: if I wanted to getthis library (hopefully) working with Rollup, should I _just_ fork it, or submit a PR once I'm done with it?
you more than welcome to fork it, but I think I'm going to get this all working with typescript quickly, as it shouldn't take me more than an hour. I should have something up here today or tomorrow, so it might be a good idea to just hold out till then. Ill also update the examples and such... thanks for the support by the way :)
Good news, nearly done with the port and architectural upgrade :D I think everyone is going to dig this new build, its vastly better designed now.
Nice! At first I thought you meant it as "it's somewhere on my backburner, will get to it at some point", didn't expect it to be _this_ fast! :D
@dylanvorster does that ;)
Any chance for a "dev-obviously-unstable" branch, or do we just wait for the master to land? ;)

nearly there :)

The hype. It's real.
(No but seriously I hope I'm not nagging you, I kinda hyped myself into thinking about a weekend project I have in mind :D)
just pushed a dev branch, busy with it as we speak. Take a look at the test directory for an example of how it works after the change. Its got a full OOP model now with an event driven layer. It now supports multiple selections as well. It shouldn't be long now until it all works and is optimized to how it used to be.
Whoop whoop :) Looking good :D
and with that, I think its done and merged to master :D let me know if you need any assistance etc..
Hmm, looks like the issue's not 100% resolved, exactly, but I think it's mostly due to tsc doing something dumb:
In main.js it appears it's converting this:
export * from "./defaults/DefaultLinkFactory";
to this:
__export(require("./defaults/DefaultLinkFactory"));
Which is causing the browser to throw the following fit:
Uncaught ReferenceError: require is not defined
I'm _guessing_ it's _probably_ something to do with tsc, and there may or may not be some kind of toggle for it, but I've never used it, so it's hard to say.
On a completely unrelated note: what's the default way to remove a link (e.g. in your examples)?
thats strange, my examples under webpack are all working properly with no issues... my tsc doesnt throw any issues either.
regarding your question: on any node/link/point etc.. just call .remove()
I think i should open a 'gitter' so we can chat about all this