Project proposal: Rewriting the UI using React

[sebastian (Sebastian Kurfuerst)]

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

@wbehncke

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.

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

@wbehncke

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 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.

@wbehncke

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).

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!).

@wbehncke

Rich Text Editor

Let’s continue the discussion over in this thread instead 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 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