Show HN: React Oxide: open source ReactJS code editor with tabs, files & webDAV.

It's a minimal code editor that runs in a browser. MIT licensed, code at: https://github.com/bootrino/reactoxide

I wrote React Oxide because I needed a simple code editor but couldn't find something that included editor, tabs, a file tree and file management.

You can see a YouTube demo at https://youtu.be/OmxKAWeN38I

You can see a live demo at https://www.reactoxide.com

It use the Microsoft Monaco editor https://microsoft.github.io/monaco-editor/

It's written in TypeScript.

The React code is written in a style I call "Event driven React", which means inter component communication is done via event emitters rather than using global or lifted state. So state is almost entirely managed at a component level. I did this because I find state to make React applications complex and hard to debug, whereas this event driven approach I find easier to understand and write. I would not be surprised if someone comes along and tells me why it's a bad idea, but so far it seems to work - perhaps someone can let me know what the drawbacks are of such an approach.

I guess as long as long as the component hierarchy fits in your head, it is likely straightforward to reason about all the event interactions.

The lifted state model ala redux (and similar alternatives) doesn't suffer from this problem.

I personally prefer effector [1] these days because it combines the convenience of event emitter with multiple stores and you usually find yourself thinking much less about what changed the store causing my component to rerender much less often.

[1] https://effector.dev/

* It looks like you're creating an emitter wrapper around an EventEmitter instance, freezing it, then exporting the instance rather than the frozen wrapper[0]. I see .on() and .off() are wrapped here, while the project appears to use .addListener() and .removeListener() instead.

* As a typescript project, I would recommend using typed-emitter[1]. Not only does it ensure you're only emitting recognized events, it ensures that the type of the payload is correct for the corresponding event. Currently, your typed handlers are coercing from `any` as far as your IDE is concerned, rendering it unable to help prevent you from mistakes.

* Instead of plumbing an emitter prop everywhere, even through components that don't interact with it directly, this looks like a better fit for the Context pattern to create the global emitter instance in a top-level context provider, then getting a reference to the emitter via useContext[2].

[0] https://github.com/bootrino/reactoxide/blob/master/reactoxid...

[1] https://www.npmjs.com/package/typed-emitter

[2] https://reactjs.org/docs/context.html

How does this differ conceptually from Redux and the general dispatch/reducer architecture? would be interested in reading more about your approach.

> There's no tests - and I'm not writing any - I made this project for me and I don't need tests.

Not exactly production ready!

Is it purely because nobody seems to care unless a GUI is built with it? You just want to be popular, that it?

You should really try using Vue. Everything boils down to event systems anyway