Here's what I'm trying to do---add a listener to a fluxible event to do an ajax call. In Redux, this is called a side effect and there are several ways of doing this (ex: create "side effects" using redux-saga, which are just listeners that do stuff). In Flux, one approach is to do side effects in the Store.
What about fluxible?
From what I can tell, the way to do this is in the Store. But I don't see a way to get the context. So perhaps there's another way to do this?
You should do ajax call in action. Action receives context, where you could provide plugin to do http call. Stores should contain only application state and have only synchronous code.
Related
In my app I got service classes like SpeechRecognizer, VoiceRecorder ...
I wonder should I put them into the state of application, my personal opinion that they don't form the state, so then where to put them.
Also to notice, SpeechRecognizer is initialized with callbacks that are called when certain event occurs, so who shall subscribe to them and how to implement that subscription ?
I've looked into consuming APIs in Redux using the redux-thunk middleware. I understand the flow of calling an API from Redux, and I understand how to structure a slice of my state to reflect the status of an API call, i.e. fetching, success, or fail. What I'd like to know now is: how do I structure a very large application to avoid boilerplate code? From what I gathered reading the docs, a single API call requires:
Action creators to dispatch an API_CALL_FETCHING action and an API_CALL_SUCCESS action or an API_CALL_FAIL action
Reducer code to handle each of the actions
A slice of your state dedicated towards reflecting the status of your API calls
Assuming I have a resource that allows basic CRUD operations on it, naively that means I should write 12 different actions (4 crud operations * 3 API status actions per call). Now imagine I have many resources that allow CRUD operations, and this starts to get huge.
Is there any eloquent way to condense the code necessary to make many API calls? Or does having a large application simply demand lots of repetition in this area?
Thanks!
Yes. There's numerous ways to abstract the process of making API calls, and dozens of existing libraries to help with that.
Generically speaking, you can write "factory functions" that take some set of parameters (API endpoints, data descriptions, etc), and return a set of actions, reducers, and other logic for actually making the API calls and handling the data.
For existing examples, see the Action/Reducer Generators#Network Requests and Entity/Collection Management sections of my Redux addons catalog. There's also some more intentional abstraction layers on top of Redux, like redux-tiles and Kea.
I have just completed my first API in Apigility. Right now it is basically a gateway to a database, storing and retrieving multi-page documents uploaded through an app.
Now I want to run some processing on the documents, e.g. process them through a 3rd party API or modify the image quality etc., and return them to the app users.
Where (in which class) do I generally put such logic? My first reflex would be to implement such logic in the Resource-Classes. However I feel that they will become quite messy, obstructing a clear view on the API's interface in the code and creating a dependency on a foreign API. Also, I feel limited because each method corresponds to an API call.
What if there is a certain processing/computing time? Meaning I cannot direct respond the result through a GET request. I thought about running an asynchronous process and send a push notification to the app, once the processing is complete. But again, where in the could would I ideally implement such processing logic?
I would be very happy to receive some architectural advice from someone who is more seasoned in developing APIs. Thank you.
You are able to use the zf-rest resource events to connect listeners with your additional custom logic without polluting your resources.
These events are fired in the RestController class (for example a post.create event here on line 382).
When you use Apigility-Doctrine module you can also use the events triggered in the DoctrineResource class (for example the DoctrineResourceEvent::EVENT_CREATE_POST event here on line 361) to connect your listeners.
You can use a queueing service like ZendQueue or something (a third party module) built on top of ZendQueue for managing that. You can find different ZF2 queueing systems/modules using Google.
By injecting the queueing service into your listener you can simply push your jobs directly into your queue.
I'd read it somewhere that whenever one needs to do data intensive work then Webapi could be used. Ex: autocomplete textbox where we get data from using ajax on key press.
Now someone told me that Webapi shouldn't be used within applications which are not externally accessed. Rather action should be used to the same work as it is capable of returning the data back in a similar fashion to webapi.
I'd like to know your suggestions over it.
Depends on how you look at it. If all you need is ajax-ification of your controller actions, then you really don't need Web-API. Your actions can return a JsonResult and it is very easy to consume that from your client side through an AJAX call.
Web-API makes it easy for you to expose you actions to external clients. It supports HTTP protocol and Json and XML payloads automatically, out of the box, without you writing the code for it. Now, there is nothing preventing you from consuming the same Web-API actions from your own internal clients in an AJAX manner.
So the answer to your question depends on your design. If you don't have external clients, then there is no string need for you to have Web-API. Your standard controller actions can do the job.
I am developing a rather large application and would like to implement IErrorHandler multiple ways for different conditions. However, it appears that ALL of the instances will be called for every error. Is there a way I can tell WCF that the error has been handled by a particular instance so that any handlers remaining in the list are not called?
(For a little more detail, we are using a 3rd party toolkit that adds a "default" error handler. This means that no matter what we do, this handler will be invoked and reverses some of our changes.)
You could just use a provider pattern and inside it have a list of your error handlers. You could then have whatever condition you like to delegate to the handler of your choice.
Ie you would hook up 1 error handler that contains all your handlers instead of hooking up many which all get executed sequentially.