Fixation of architecture and its documentation

[k00ni]

• Reduce information to the essence we talked about
  • exact data flow (flux!)
  • required elements in flow (RDF store, a Redux store, container and component ...)
• fixate file structure
  • use "by nature"
• create a list of required libraries (vendors)
  • which library is used in which part of the application?
• plan a basic test concept (keep existing unit tests)
  • deploy new folder structure
    • please use https://github.com/AKSW/cubevizjs/tree/develop/test as example
  • mocking of Redux stores
  • add a system test which uses rdf-store + redux store + container to query the store via SPARQL and expect a certain list of triples (JSON-LD)
• important: usage of technologies which allow execution on old browsers like the ones on Android 4.0 or newer
  • please research if there is a library or test tool to check availability

All the information you write will result in the future README.md.

[simeonackermann]

First quite reduced draft of the architecture with required elements.

Especially the "Action API" will have additional elements like functions/interfaces/classes etc to request the Store, build the Filter etc. Shall I add these to the architecture diagram?

[simeonackermann]

A more detailed version with additional elements:

[simeonackermann]

I figured out an important update of the flow between the actions, rdfstore and middleware.
We can use the middleware as an API to do asynchronous requests to the rdfstore and pass the results to the redux-store.
The new architecture might look like this:

A description will follow in the Readme...

[k00ni]

Thanks for the sketches, they look good already. But i dont understand, why we need the Middleware API? The container is already subscribed on the redux store and therefore gets called, if anything changes. This kind of asynchronization is already there, why the Middleware?

[simeonackermann]

In the first sketches the asynchronous call to the rdfstore was made in the action API. But this was wrong. The actions are mainly for synchronous calls to the Redux store.
With a custom middleware we can do an asynchronous call to the rdfstore, fetch places and dispatch them to the Redux store. Therefore the middleware wraps the dispatch function and is independently from actions.

[k00ni]

The middleware is basically the handler of asynchron request/responses and delivers. Therefore it makes sense. So the container doesn't wait for something, just fire and forget. But gets called, if an update arrived. This way?

[simeonackermann]

Yep, thats the way.
And while the sync request is working, the container can subscribe to an 'is-fetching' state, to may view a loading icon.

[k00ni]

Ok, sounds good. What are your next steps?

[k00ni]

Which bullet points can be already marked solved in the list above?

[simeonackermann]

With the updated Readme and source we can check the first three points.

The new test concept is still on progress.

[k00ni]

Very interesting article how to structure a React application: https://medium.com/@alexmngn/how-to-better-organize-your-react-applications-2fd3ea1920f1#.a0y594u1s

[simeonackermann]

Yep, had this (or a similar) article in mind when creating the architecture. But we decided against it because the structure overhead. But with current folder and file structure I would see some advantages in using more filigran separation. Am 17. Januar 2017 10:47:07 MEZ schrieb Konrad Abicht <notifications@github.com>:

…

Very interesting article how to structure a React application: ***@***.***/how-to-better-organize-your-react-applications-2fd3ea1920f1#.a0y594u1s -- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: #6 (comment)

-- Diese Nachricht wurde von meinem CyanogenMod Android-Mobiltelefon mit K-9 Mail gesendet.