[feature] Post an article with steem.connect.comment method on this page https://bus.yt/write

[busyorg]

[feature] Post an article with steem.connect.comment method on this page https://bus.yt/write

[yamadapc]

This is done in the commit above, however, there're quite a few things that IMO should be done. The most important for me are:

• 1 - The form state should be managed by the store as well as validation. I'm not sure what the best way to do this is, but react-form seems like a popular choice.
• 2 - All this redux CRUD boilerplate can be avoided by using a model framework (backbone, ampersand, maybe lorejs) and syncing it with the store, if [...]
• 3 - Steemconnect.com should follow HTTP standards and expose a convention driven API

follow HTTP standards

Creating things responds with 201, things being good respond with 200, proper error codes throughout; 400, 422, 401, 403, 502 will all be common.

expose a convention driven API

The post/comments API should have the structure:

fullPermlink could be the /:category/:author/:permlink url encoded. This is similar to what GitLab does. But the URL doesn't matter here.

POST /api/v1/comments/
GET /api/v1/comments/?filter=...
GET /api/v1/comments/:fullPermlink
DELETE /api/v1/comments/:fullPermlink
PUT /api/v1/comments/:fullPermlink

The votes API should look like

POST /api/v1/comments/:fullPermlink/votes

Or something like that.

This sort of convention makes it very simple to take something like ampersand and minimize the amount of boilerplate code for API integration. A framework with swagger support like loopback could also have a similar effect.

[p0o]

Are all these points related to the same issue? Breaking these down into separate issues would help to discuss easier about each part. I'm interested to learn more about this:

All this redux CRUD boilerplate can be avoided by using a model framework (backbone, ampersand, maybe lorejs) and syncing it with the store,

Are you talking about ampersand collections? I'm not sure how valuable it is as I feel it may actually change the core principles of redux design pattern. I'll be interested to see an example of combining these two together.

[yamadapc]

Are you talking about ampersand collections?

Yes, collections and models; if there's a custom transport (i.e. not HTTP), a custom sync method.

I'm not sure how valuable it is as I feel it may actually change the core principles of redux design pattern. I'll be interested to see an example of combining these two together.

You can sync the store with the model layer. It does break the principle of CQRS/unidirectional data-flow, but if you're really worried you can generate actions to manipulate models and read them from the store.

So, I'm not sure of the solution, but the value is in:

• Not writing transport bound code
• Not hand-rolling a transport independent abstraction
• Not writing dirty entity management (isLoading)
• Not writing pagination management
• Not thinking about indexing
• Not thinking about standard API change resiliency
• Not thinking about standard mapping of memory state to protocol
• Not writing update/create/delete action mapping (you can generate an action function saveUser(userId) { return ({collections}) => { payload: { promise: collections.usersCollection.get(userId).save(); } }

It's not a pristine command architecture, but some layer like that feels very useful to me. Again, I'm not sure about what the layer should be exactly, but that all of these things need to be solved in some way or another.