Project proposal: Rewriting the UI using React

The Neos Project Accepted Projects
1

Hey guys,

so @wbehncke and myself spent the time between christmas and new years eve working on a prototype for a complete rewrite of the Neos UI, as a separate package, written in React. Basically which was decided months ago in a hangout.

We know that on the last codesprint in Frankfurt it was decided that the update of the ember codebase is the way to go, and we respect that decision. Still, we see a lot of exhaustion and frustration of the people actively participating in the update process (myself and @dimaip f.e.). This, as well as the arguments which where written out in the refactoring RFC[1](RFC: JS Refactoring Process of Backend), where reasons enough for us to start writing a prototype from scratch.

We set ourselves a limit of about three days, and wanted to see how far we will come with the stack based on React/Redux. Long story short, the progress is huge, we haven’t thought that we will get that far in such a short time.

  • We’ve completely written all UI components from scratch in a abstracted way
  • The data-flow is based on redux(data-down-actions-up)
  • The data itself is immutable, to reduce side effects and simplify the data transformations
  • We’ve splitted the whole code base into three parts (Guest, Host and Shared(API))
  • As you may already noticed from the wording above(Guest/Host), the target website(Guest) is loaded in an iframe, a lot of problems are solved already with this feature.
  • We’ve updated Font-Awesome to the latest version, with an on-the-fly migration.
  • We’ve removed all of the bloated libraries of the current Stack(Aloha, VIE and Create.js) and replaced it with a simple inline-editing expierience based on Medium-Editor - Note: This is not the final decision
  • The CSS of Neos isn’t global anymore, so no side effects at all.
  • We’ve replicated about 30-40% of the UI logic.
  • Better performance in the UI, not only load times but also performance on low-budget PCs
  • Working Page-Tree.
  • Working inline editing.
  • Publishing is also working fine.

A short video demonstrating the current state is located on youtube, go ahead and take a look at it!

… or setup a Neos demo site with the UI package, based on the installation instructions on GitHub - The code itself is open sourced, and available on GitHub.

Both of us spent about 10 workdays in total working on the prototype. Please note, this is a prototype, some things may not work, or miss some features of the current UI, we just wanted to demonstrate how far you can come with such a short amount of time with the right tools.

So why am I posting it here, you may ask.
Today Wilhelm and myself had a meeting with @robert and @christopher where we’ve presented the prototype to both of them. This was a test to see if the work would be accepted by core-members/elders, who were with Neos from the beginning.

Both were pretty stunned about the process, and we all agreed that this approach would totally be in line with the Product Vision which is currently being discussed at Product Vision Flow / Neos.

We know the fears that come with a complete rewrite, and we can understand them of course. But we need to remind ourselves that starting from scratch is not always a bad decision. Currently the ember update is in process of being worked on. I myself made the starting point for this whole thing on the second last code sprint in Nuremberg, this was in August I think(Correct me if I’m wrong).

So 5 months forward, the update is still in progress, and it seems that this won’t change anytime soon(Again, correct me if I’m wrong). Please note that we don’t want to be rude to anyone who is currently involved in the update, these are just observations we made from the distance, we know the struggle which is involved in the update, and respect the work that the people have made, but we don’t think that the update will succeed anytime soon. And even if that’s the case, we still have the problems of the iframe integration, no API surface, a bunch of libraries which bloat the current code base and so on.

Our proposal

  • Create a separate Neos.UI package based on our work.
  • Stop the current update process of Ember, and spend the energy in maintaining the current ember code base (bugfixes etc.)
  • Anyone who would like to join working on the new UI package can do so, we would like to transfer the repository as soon as possible to the official Neos GitHub account
  • For people who don’t know react, but would like to learn the paradigms of it etc, there will be a support channel in the official Neos slack. We also plan on giving a free React training on the next code sprint.
  • Based on our estimation, the current Neos UI will be replicated before the 2.3 release of Neos.
  • Until then, we will launch a public alpha/beta, and anyone who would like to test the new interface package can do so simply by installing it.
  • We will make sure that no migration is needed by using the UI package, so if someone dislikes it, he can immediately switch back to the default UI of Neos.
  • With publishing the next major version, the old ember code base will be deprecated and replaced by the new UI package.

Benefits

  • A clean code base, written from scratch without code that isn’t needed anymore
  • A flexible and lean code base, with a Content-API which will be integrated soon
  • A modern stack of technologies, which will attract new (Frontend-)developers
  • The possibility to create an individual iPad/Android-App with React-native later on
  • No ties to a big framework for extensions of the UI - Let it be inspector editors, or whole new sections in the UI. The developer should chose what type of JS framework he/she would like to use to extend the Neos UI.
  • A fully customizable/themable UI, which can be extended on the fly - This is a major feature of the product vision stated above!
  • A fully test covered UI package/API

Disadvantages

  • A learning curve for those developers who are not familiar with react/redux (We will help anyone who wants to learn that stuff, see the proposal above)
  • Possible missing features (This should be covered as well by the public beta/transitioning process)

In the next hours/days, we will attach a voting to this topic, and hopefully in the next few weeks have a decision regarding this prototype. Again, we don’t want to back-stab anyone here, we only want the best for this project, that’s why we created the prototype.

Could anyone add a voting to this topic? It seems that I can’t create one here on discuss somehow…

[ ] Agree to the proposal
[ ] Abstention
[ ] Against the proposal

6 Likes
2

CC: @aertmann @sebastian @gerdner @dfeyer @radmiraal @gerhard_boden @kdambekalns

3

I like the idea of doing a complete rewrite.
But i definitely don’t like the react/redux stack.

I’m in favor of using ember-cli for the rewrite.

4

I like the idea of having a completely separate UI package as also stated in Product Vision Flow / Neos

Regarding the framework: I decided to stay away from such discussions, so I abstain.

1 Like
5

I’m not 100% sure if I should have a say in this, becaue I’m new to JS frameworks and therefore was unable to contribute anything to the ongoing Ember 2.0 upgrade (I read that even experienced JS coders have a tough time with it, so I would not have been of much help).

Anyways here are my two cents:
First of all I’m stunned what you guys pulled off in just 10 days! The demo video looks really good and it looks like many things are working already. What I love most about it as a developer (working closely with editors): The iframe integration. Finally the backend view looks the same as the frontend (especially on smaller screens, because all the media queries are in effect). This would be a huge step forward for the mobile backend support as well!

As i said in the first sentence: I’m not sure if I should decide what other people have to work on, so I’ll abstain.

[ x ] Abstention

BUT in case the majority of the guys that put a lot of effort in the ongoing switch to Ember 2.0 agree (like @aertmann, @dimaip, @gerdner, sorry if i forgot someone) to this change I would definitely vote for

[ x ] Agree to the proposal

Because i see a lot of potential and momentum here (two guys, 10 days). Plus the benefits and new features look very promising to me.

6

Thanks to @inkdpixels and @wbehncke for creating this proof of concept and explaining the motivation for choosing React / Redux. It definitely helps to weigh off React against Ember.

But before we start voting let’s keep this thread open for questions and possible discussions for a week or so. We shouldn’t take this decision lightly and reach a consensus before we proceed. I suggest to start a formal vote next Friday, 22nd and leave the voting open until the following Tuesday, 26th. Everybody who thinks that he / she can assess the impact is invited to vote. For the actual decision, we will, however, only count the vote of the Neos Team.

Please ask any question, raise concerns, point out benefits now and during the upcoming week, and let’s then take a decision so we can proceed.

3 Likes
7

I was pretty much neutral all along the way. I have worked on the very first ember prototype back then and also had a look at the ember update process last year.

I am currently not doing a lot of JS stuff and so refrain from technical discussions about react vs. Ember, but what I see here from a team/project perspective is an active group with an idea and the will to push it. The demo is already quite impressive and a short look at the code shows me that it definitely won’t be harder to get into this than into Ember. Especially looking at the group of people working on the Ember update and the time being spent on that I think this here is definitely a possible way to go. I also think we should let this sink in for a moment before we start voting, but already now:

THANKS A LOT GUYS :clap: :dancer: :tada:
Awesome work and dedication, I like

2 Likes
8

My background: I am a beginner / intermediate Ember dev, have only roughly played with Ember CLI and know React / Redux only from reading articles and the presentation @wbehncke gave us yesterday. So I can’t judge this from a practical background but only from an architectural standpoint.

The biggest benefits I see in choosing React / Redux are

  • it allows us to create a very fast and portable UI (React Native!), which improves UX and is a strong selling point
  • the approach fits pretty well with what I hope Flow / Neos will use in mid term, namely CQRS and Event Sourcing. As far as I understand Redux, that really helps us with CQRS in particular (see also motivation for Redux)
  • the React community grows fast and its more likely to find React devs than Ember devs for our growing team
  • React is really lightweight
  • for someone who already knows Ember or is skilled enough for handling Neos at present, I don’t think that learning React will be a real issue

Drawbacks:

  • React is using all the latest technology, so every will have to learn not only React, but also Redux, Immutable, ES6, JSX, Babel, and probably much more (Webpack, Socket.io …). But maybe it’s not bad to keep learning in that area too.
  • React is moving fast and as @christopher also brought up, it can be a daunting task to keep your code adjusted to the latest React releases

In general about the term “rewrite”: since we switch technologies, we of course need to rewrite the JS part. But, to be honest, even if we’d stay with Ember, we would have to heavily refactor the code anyway, which might take the same time.

But in order to minimize the risk, and also because we have to in general, this project will have a strong focus on defining and implementing a good web service API, which will be used by any existing or upcoming user interface. So even if the React project would fail (which I don’t expect from how it looks now), we still would have a better API as one outcome.

Finally, we also need to consider that we now have the two volunteers from sitegeist, plus @dimaip and certainly others, who will put a lot of energy into this - but possibly only if it is React. While we shouldn’t put ourselves the screws on by that and only take the decision in favour of React because they fancy it at the moment, the reality is that we’ll get some highly motivated developers additionally.

So, right now I would vote in favour of it. Not because I can oversee all the implications till the end, but because I think that the direction is good, the project has potentially big benefits for the users and … we should just do it.

4 Likes
9

By chance I have discovered this project a few days ago, and had a head-start to review the code. I must say that I’m very much like-minded to Tyll, and I could even say we think as the same person in regard to this project, if I had started it I would write almost the same code =)

I have submitted issues and ideas for improvement, and most of them guys already had in mind, and some of them they had fixed. I can assure that the quality of this prototype is above prototypish level, and can easily serve as foundation to build upon.

As for myself, I have successfully completed 2 projects with exactly the same stack, also used it at Yandex Interface Developer School, so I already feel comfortable with it, but am sure I will have a lot to learn from such complex project as the Neos UI.

I’m going to March sprint and hopefully to April sprint, so that would be a good dev time investment already. Also I’d try to get some of my work time sponsored for this project too, besides sprints.

2 Likes
10

Hi there,

thanks again to @wbehncke and @inkdpixels for taking the initiative here (and being patient even if previous discussions seemed a little bit like a bummer).

So after talking about that proposal yesterday in person I have a pretty good feeling about this. Of course I still see a lot of risks and I think we need a few discussions here and there about details, but we should take this chance to move the frontend part of Neos to a new level.

[x] Agree to the proposal

11

I tried this new UI on our main site.

This page takes 18s to load in current Neos interface (you can imagine working with it was a nightmare, especially with actions that require page reload…):

Selection_011.png1400×418 95.2 KB

The same page takes 1.5s to load in the prototype:

PS: I know it’s not really fair to compare the performance as the UI is not yet fully done, but just to make the point.

3 Likes
12

Awesome, thanks for the hard job. I will spend some hours this week-end and next week to do a more deep check of the code base. Nice to have some thing real to make a decision.

My first point to keep Ember, is that we have tons of experience with the tools. And “yes let’s build it from scratch” … sound always horrible to me by experience :wink:

I open to anything, but as discussed with @sebastian we need a decision soonish to focus to workload in the correct direction.

PS: I know it’s not really fair to compare the performance as the UI is not yet fully done, but just to make the point.

Don’t do benchmark, never, never … it’s not fair :wink: but please I want the same bench when the UI is fully implemented.

So if we can be the next hot CMS with a really hot UI, why not :wink:

Edit: My level of React & stuff is definitively not good enough to say anything about the code, but I love what I read, structure, clean, … understandable will be the next step for, but open to learn.

Looking at guy like @wbehncke, @inkdpixels and @dimaip we have our JS team focused, now the challenge is to follow the young guys :wink:

So for me the risk has now moved to the API. As said in other post, I think taking inspiration on existing API (and maybe just use the same API), from other content repository as a service (Prismic, Contentful, GatherContent …) should be really cool. Imagine Neos with a decoupled UI, but compatible with tools build to work with major player in the area …

1 Like
13

Hey everybody,

I’ve taken some time to write this reply, as I wanted to play around with React first, get the prototype running locally, do an in-depth code review and start hacking on the prototype, and submitting my first PRs to it.

Thanks @inkdpixels and @wbehncke for your work on this, I think a specific prototype really helps to judge things.

Following are my personal reflections – so take them with a grain of salt :wink:

The Good

  • I really like the code structure in the prototype.

  • Working with the immutable data and domain-specific commands to mutate that data feels really good to me, and will fit well with Event Sourcing on the backend side.

  • The whole code-base reminds me of clojure’esque-functional-style-programming. (Which I enjoy writing and thinking about!)

  • Having global, immutable state describing the whole app (in Redux) immensely helps debugging and tracing what is going on – I especially like that we essentially get a time-travelling debugger for free.

The Bad

(don’t worry that this part is “longer” than the “good” part above; as I tried to include possible solutions and ideas to start a discussion how to resolve these issues)

validating global redux state

I feel that the global Redux State is at the one side a blessing, at the other side a “curse” in the sense that everybody must extremely well understand how this state is structured, and if this state must be restructured, we must be quite careful to do this.

Solution idea: To me, the current Factory.js contains way-too-little documentation; or maybe we can create a JSON schema against which the state is validated. This would in my opinion circumvent this problem.

What do you think?

fast-evolving NPM & React Ecosystem

I have the feeling that as soon as we decide on some package / dependency, it is already outdated & a “better” alternative exists – so we could basically “update our packages all-the-time” without creating value. Often, packages also get deprecated quickly and superseeded by “better” alternatives.

That’s just something which I feel is the case in the NPM ecosystem in general, and the React ecosystem in particular.

There’s a thin line to this problem:

  • If we update/switch libraries too conservatively, we end up in the same mess we’re in now with the Ember 1.x codebase (where we did not update libraries, switch to Ember CLI, …).
  • If we update/switch libraries too often, we’ll be reorganizing the code again and again without creating value.

Solution idea: I think this is just the way it is; we just need to be aware that this is a long-term effort for the whole team.

Code Conventions/Best Practices to code-organization “non-obvious”

Granted, the tagline is a little “bold”, but basically I have seen tons of React starter-packs claiming to be a “best-practice” way of building react apps, which connect together the libraries in many different styles. So while the rendering using React is always fundamentally the same, how you organize your code is different from project-to-project.

This means we have to come up with our “own” style of creating React projects (which will be based on what Wilhelm and Tyl did of course). We did the same in the past with EmberJS (in combination with Require); and Angular 1 projects suffer from the same problem.

This hit me once more when recognizing the tremendous value of Ember CLI in the Ember Ecosystem; which basically means that all Ember projects look, feel and behave the same. And you do not need to document it, but can just point people to the well-written ember-cli docs. Not to speak about all kinds of testing which works right out of the box, and the addon system.

However, as we’re currently creating our own Content Management Platform, this is less of an issue, as people will adapt to the code conventions we prefer. We don’t know if in a year from now, a platform/build-tool like ember CLI might become the de-facto standard for React tooling. If so, we might think of switching. But that’s nothing we need to handle now.

Solution Idea: For me, it would be really helpful to have a LIBRARIES.md document in the codebase, which contains the following information for every library we use:

  • Short-Description of the Library explaining its role in the project (e.g. “immutable.js provides immutable JavaScript objects, lists and maps, inspired by languages like clojure. Immutability benefits: time-travelling debugger, global undo-redo, …”).
  • short explanation of interactions with other embedded libraries (e.g. “immutable.js is used inside the redux store”)
  • Alternatives with a short explanation why this one is not (yet) used (e.g. “Freezer.js is too immature compared to immutable.js, but could be an option lateron.”, or “mori.js is not maintained anymore”). I also imagine that when we find new libraries, we add them to this list, so we can periodically review it and decide whether we need to update or switch the infrastructure.

Ember (2.0) vs React

I couldn’t resist to write this small part, as IMO a few people were bashing Ember 2 a little :wink:

  • Ember 2.0 has been heavily inspired by React, but is more of a holistic framework than React. When I checked the code, I think one could have built a similar-looking codebase in Ember 2.x.
  • For me, a clear benefit of the React platform (the way it has been built in the prototype) is its enforced state immutability and functional-style programming.
  • Ember I think is platform-wise more mature; because of Ember CLI all “modern” Ember projects look and feel the same.

Comparing the current Ember 1.x-grown-codebase to a “new React” codebase is I think of little value; as the comparison would be quite similar comparing the 1.x-grown-codebase to a clean start with Ember 2. Maybe the idea to “upgrade from Ember 1 to Ember 2 using the compatibility layer” was a bad idea in the first place, as the compat layer adds quite some overhead and difficult-to-debug behavior.

Also comparing performance numbers is really hard; for the same reasons. I have seen various Ember2 vs React benchmarks; and depending on the metrics you look at, the one or the other is faster (depending on the use-case and measurements).

Summary & Conclusion

In the end, I think the decision between starting fresh with Ember2 or starting fresh with React is a matter of personal preference and sort factors, not hard, technical ones. With both technologies it would be perfectly possible to build what we intend to archive.

Knowing ember, I was able to get productive in React really quickly, and it felt generally good. Sometimes a little more high-level than ember, sometimes a little more low-level.

There are some soft factors speaking in our case in favor of React I think:

  • We have a working prototype already which I’d be comfortable extending.
  • React is currently “hip” and “hyped”, meaning we can get lots of exposure in this community, and can somehow “ride” that hype wave.
  • We can grow the Team by @inkdpixels and @wbehncke (I hope).

Summary: Going the React way is fine for me, and I’ll support it whereever I can.

Suggestion: Next Steps

I think the rewrite is a big task and I see a lot of work coming up. There lots of features deep inside Neos already, which would need to be re-created (e.g. like Content Constraints, updating the URL, all the editors in the inspector, drawing editor borders, preview modes, dimensions, to name a few).

So for me, there is no guarantee we will make this transition reality; it is a rather high-risk project. But if we manage to finish it, I am sure we’ll be happy with the results.

That’s why it is extremely important that we as a full team pick up this task and commit to it. If only one (or two) people work on it, that will likely not work.

UI wise, I’d focus on re-creating the current state in a more bug-free manner. However, there’s one thing I’d do right from start, and that is integrating CKEditor (for the reasons described in this RFC). CKeditor will be included in NPM really soon, see this issue. And we have great support from the CKEditor team!

The End.

Wow, that was a long post. Took me about three hours to write, but I think it was worth it :wink: Thanks for reading and I’m looking forward to the upcoming discussion and decisions. I see a consensus coming up!

All the best,
Sebastian

4 Likes
14

I trust your technical decision here and decided to not look deeper into it myself, I already gave my :+1: for the soft facts so from my side good to go. But me being me I want to add a few points that should not be forgotten while doing this:

  • This will be a breaking chance no matter what as we allow custom editors and validators and the code needed for this will probably change
  • The beforementioned extension points have to be keept and new ones need to be deeply embedded into the rewrite IMHO
  • While at it we should think about reuse of components for (custom) backend modules, but I guess @dimaip will have an eye on this
2 Likes
15

Just wanted to correct my fanboyish tone here a bit. I didn’t post this comparison here as an Ember vs. React thing, I’m not that stupid and perfectly aware that we could get similar performance from starting a fresh with Ember.
It was just a shout of relief from long pains with current UI performance and was more in favor of rewrite with iframe than anything else. Yet internet communications are not my strong side so please forgive me for that :slight_smile:

1 Like
16

I think the best sort of validation and documentation here is writing more tests, and that could serve as such “schema” and documentation. And we should be truly test-driven here, i.e. first write tests then code. It’s very easy with functional style of code.

Yes, there’s always this discovery effort with npm ecosystem. But it’s more about ideas than about actual code libraries, usually a module encapsulates some new way of thinking, and it feels more like a refactoring we have to undertake anyways, just outsourced to 3rd party modules.

Great idea, like it.

17

Hey @sebastian,

thanks for taking the time to have that detailed look on our prototype. I really appreciate your comprehensive feedback and will try to give some insight on what our thoughts on this are:

We agree that validation is a huge concern when dealing with this kind of data structure (which not only regards the store but also actions for example). @inkdpixels already had a look on GitHub - molnarg/js-schema: Simple and intuitive schema validator for validating actions on reducer level - it could be helpful for the store as well.

But I feel that the schema (with whatever tool it will be described) should not be our single source of documentation regarding the store. To completely understand the overall data flow, besides the static structure of the store, one must understand what smart components expect the store to deliver and what portion of the store reducer functions are going to mutate. Component-wise, I think, the @connect decorator does a great job for developers to immediately understand what section of the store is displayed by a component. Reducers on the other hand will profit from unit testing.

I also agree with @dimaip that testing will be worth a great deal to support the contractual character of the store, but runtime validation is definitely also important, since it helps to sort out corrupt server state.

I have been pretty overwhelmed by this as well when I started working with these tools. But after a while, I was under the impression that this speed of progress is actually healthy. Whenever a particularly better solution comes up for a problem, there’s no better time than right now to fix it. And the smaller your dependencies are (in amount and size), the more easy it will be to manage updates for them. Luckily, most of the npm-libraries innovate as fast as they ship, so change is not introduced in huge amounts. This might be just a feeling of mine, but I think that adopting progress doesn’t look like one, but is an overall time-saver.

I like the idea, but I would be afraid of this to die pretty quickly (just my experience with '.md’s other than README). But I do see the point of documenting third party libraries in such a way, so I would give it a shot.

I agree with prioritizing the recreation of the current UI, with keeping the benefits of some new paradigms in mind (like the I-Frame integration) - so that we will once in a while reflect on exisiting features, when and if they could be replaced with a better solution along the way (I don’t have anything particular in mind, but I feel like we should not be dogmatic about things, when there’s something better and more work-effective ahead).

The one I can not easily agree with is CK. I absolutely respect the level of sophistication behind this software, and certainly think that it is superior to aloha, but I do have great doubts if it is the right solution for Neos. It is just huge! Why should Neos integrate a Rich text editor, that looks like it aims to be a CMS itself? In my daily experience working with Neos, I always try to restrict the feature-set of Aloha (Which I can’t even do to the degree I would like to). With CK, I would have to reduce the feature set of a battleship down to that of a canoe - for me there would literally never be a scenario in which I could use a full blown CK in a project.

Of course I can only speak for myself, but I think this is a question of how much control you would like give up for a larger rich text editing experience. I always felt like restriction is the way to make the system more usable for editors.

I could live with CK as the editor shipped with Neos though (assuming it works as an npm depency) - but I absolutely disagree on the integrational part.

Our prototype is already agnostic about inline editors and I really would like to keep it that way. When Neos is actually able to provide a way to extend the inline editing feature with custom inline editors, this would be a huge win for the end users.

…

So, now I’ve written a lot myself :slight_smile: I’m very happy about all the great and constructive feedback so far and really have the feeling, that we’re on the same page on most of the issues. And I’m really looking forward to figure out solutions on the remaining ones with you guys

@sebastian Thanks for the PR’s btw :smile:

Have a nice weekend!

Wilhelm

18

Reading those posts I can only say “I’m happy to read this”. As a complete rewrite was (from the beginning) my most favorite solution although I heavily worry about the time it might take / breaking changes that also @christianm mentions. The main advantage is see from the full rewrite is that it gives us the chance to completely separate the UI from Neos / CR. In line with that I’d like to state that it would be a wise decision to

  • add a (REST / whatever) API to CR
  • add a similar interface to Neos for the domain specific stuff
  • make Neos just a ‘content management framework’ that is able to load a backend UI
  • make the now discussed rewrite the ‘official supported’ version but keep in mind that companies will write their own backend too

Regarding Ember vs React: as long as the stuff is clearly separated and has enough support from the team I’d be fine with either of them. Downside of my current view on that is the point I became tired of the framework discussion as a whole (also outside of the Neos project btw). Been there, done that… So let’s see what the future brings, maybe React might even make me more excited about the UI stuff in the end :wink:

For now: great to see this all moving, and great to see open and complete responses… keep doing that :wink:

2 Likes
19

Hey Wilhelm (and also others, thanks for your comments),

Full ack, and I have to admit I am still kind of lost at this point – so I am starting to feel that we really need a good documentation/test coverage/Architecture Diagram/… at this point. So that’s something we very much need to care about :slight_smile:

I agree this might become out of date if we are not disciplined enough to do this; but I just think that we need to be very disciplined at this point, because it allows new people (which might be familiar with React) to become involved in the project at a later point in time. So for me that is crucial for improved “openness” of the project…

I think this part is more crucial in an Open Source project than in a company; because in a company usually there is a more well-defined and organized onboarding process; and a company usually grows slower than a well-developing Open Source project.

Of course, we are totally on the same side here. I just wanted to re-create the overal User Experience (in a faster & more stable way); of course the technical parts should and can be re-thought (like the iframe you mentioned; and there are ofc. lots of other parts where this might make sense!).

Let’s continue the discussion over in this thread instead :slight_smile: I’ve answered there!

I’ve been learning React, Redux and related concepts over the weekend, and this all makes sense to me. However, there are two areas which I’d like to highlight as I think they are crucial to think about:

  1. Documentation of the general architecture. I think we need to document the basic architecture, explaining how we understand the react ecosystem to be plugged together. As far as I understand right now, we have some “services/managers” (like ChangeManager) which trigger an action on the store, which then mutates the data structure. Unclear to me is yet why we f.e. need a separate factory for creating actions (like in actions.Transient.Changes.add), if we have a service layer in place which shall be called instead. To answer these kinds of question, I think it is crucial to document this for us; or at least post links to online resources which explain how we approach things and why.

  2. Structuring State, especially Nodes: I am currently feeling that we need a unified Node model on the client side, which is represented in some normalized way; and then used e.g. by the tree. But how this model looks like and behaves is IMHO extremely important to get right :slight_smile: So far I am thinking along the lines of creating a structure looking like what is the result of normalizr; along with using reselect to make e.g. provide a possibility to access children on a node.

Looking forward to your thoughts!

All the best,
Sebastian

20

Hey everyone,

Awesome to see a prototype of how Neos could be build if we started from scratch today, thanks for that.

I’ll answer in separate posts since there’s a lot being discussed here.

Currently on holiday hence my late response.