On my modal view I have two datePicker elements. I know that payload with action information is sent after each interaction, but is it possible to pass all selected values after form submission?
I only came up with solution where after each interaction selected value is cached on the server side and bound to view_id.
Hi you can achieve this by placing your interaction component inside input block type. Slack documentation says.
Any interactive components used within input blocks will not send this block_actions payload. They are included in view_submission payloads only.
https://api.slack.com/reference/interaction-payloads/block-actions
An example I have created in block kit
If you do not need to receive the block_actions events, then use input blocks like GJoshi suggests.
But if you do need the block_actions events, then you cannot use input blocks (per https://api.slack.com/surfaces/modals/using#interactions). In that case, you can add the value to the private_metadata field via the views.update call. When the user clicks the submit button, the view_submission event payload will contain the private_metadata field.
For folks who stumble upon this as I did, the answers above are no longer up to date since now slack allows input blocks to dispatch block actions. The approach of using private_metadata is still relevant in some scenarios, but just receiving block actions makes life much easier.
Simply set "dispatch_action" to true when defining a specific input block to receive a payload whenever it gets updated.
Once the user submits, you will still have access to all the values of the input data
Related
I have an application where users can take part of puzzle solving events. I have an API endpoint /events/{id} that is used to get data associated to a certain event.
Based on whether the event has ended, the response will differ:
If the event has ended, the endpoint will return event name, participants, scores etc. with status code 200
If the event has not ended, the endpoint will return event name, start time, end time, puzzles etc. with status code 200.
On the client-side, what is the best way to distinguish these two responses from each other to decide which page to display, results page or event page? Is this a good way to accomplish my goal?
Some might answer that I should already know on the client-side whether the event has ended and then query for data accordingly. But what if user uses the address bar to navigate to an event? Then I will have no data to know, whether it truly has ended. I wouldn't like to first make an API call to know that it has (not) ended and then make another one for results/puzzles.
pass a boolean isFinished and return it inside of response object. If your response object is already defined, create a wrapper that has the previous response dto and a boolean flag.
Also we did use a solution like this in one of our projects at work for a big company so I would say it is somewhat industry accepted way of doing it.
I want to send some custom properties in the attachment for interactive messages and retrieve them back in the action response. is there a way to do this?
Yes, that is possible. However, it only works well for small sets of data.
Assuming we are talking about buttons the normal approach would be to use the value field of an action to transfer custom data based on which button the user clicked back to your app. The field is a normal string within a JSON message, which is send by POST request to your app. So it can in principle contain a whole data set, not only a single value. All you need to do is include it in the button attachment that is send to Slack and your app will receive the respective value field back. (depending on what data you want to send you might need to encode it, e.g. you want to encode binary data into base64, so that is can be transferred as JSON string)
I have used it successfully in one of my apps to transfer serialized objects containing information about the user's application context.
There is one caveat though, that caused me to later abandon this approach again. As I found out the field length is limited, so if your string is too long you might end up with truncated data. In my estimation the limit is about 2.000 chars, but I do not have a definitive number.
Instead of transferring all data in the attachment, I now keep the user application context in a server session (PHP) and only transfer IDs through the value field of my buttons.
Conclusion: If you have small sets of data you can transfer them through the value field. If you have larger sets of data I would not recommend it.
I'm writing a library that can interact with a socket server that transmits data as events to certain actions my library sends it.
I created an Actions module that formats the actions so that the server can read it. It also generates an action_id, because the events parser can identify it with the action that sent it. There are more than one event per action possible.
While I'm sending my action to the server, the event parser is still getting data from the server, so they work independent from each other (but then again they do work together: events response aggregator triggers the action callback).
In my model, I want to get a list of some resource from the server. The server sends its data one line at a time, but that's being handled by the events aggregator, so don't worry about that.
Okay, my problem:
In my model I am requesting the resources, but since the events are being parsed in another thread, I need to do a "infinite" loop that checks if the list is filled, and then break out to return it to the consumer of the model (e.g. my controller).
Is there another (better) way of doing this or am I on the right track? I would love your thoughts :)
Here is my story in code: https://gist.github.com/anonymous/8652934
Check out Ruby EventMachine.
It's designed to simplify this sort of reactor pattern application.
It depends on the implementation. In the code you provide you're not showing how actually the request and responses are processed.
If you know exactly the number of responses you're supposed to receive, in each one you could check if all are completed, then execute an specific action. e.g.
# suppose response_receiver is the method which receives the server response
def response_receiver data
#responses_list << data
if #response_list.size == #expected_size
# Execute some action
end
end
I am trying to send an apple event to an application we have developed.
I want to be able to call the apple event, and at the same time pass parameters with the event. eg acctid, acctpassword, order number.
I'm not sure how to format the apple event being sent.
Is this possible?, and if so any guidance.
Thanks
Stephen
I realise that you have accepted the given answer, but you CAN send several parameters within a single AppleEvent.
The parameters are each placed in an AEDesc using AECreateDesc() and are added to the AppleEvent with 4-character code names (OSType).
On the receiving end, they can be retrieved by AEGetParamDesc (theAppleEvent, 4-char-code, ...);
AEGetDescData is then used to extract the data from the AEDesc.
You can also use lists as parameters by using AEDescList values, which are essentially lists of AEDesc values.
The AEBuildDesc() and AEBuildAppleEvent() make the whole process quite easy.
I'm not 100% sure if you can send multiple parameters with a single apple event (though I thought you could but I couldn't find anything on it), but a backup method would be, if you have control to the development of both applications, you can put all of the variables within one parameter using a format you've made to separate the variables. You can simply join them in the first app, and split them up when received in the second app.
Background
I'm working on a web application utilizing AJAX to fetch content/data and what have you - nothing out of the ordinary.
On the server-side certain events can happen that the client-side JavaScript framework needs to be notified about and vice versa. These events are not always related to the users immediate actions. It is not an option to wait for the next page refresh to include them in the document or to stick them in some hidden fields because the user might never submit a form.
Right now it is design in such a way that events to and from the server are riding a long with the users requests. For instance if the user clicks a 'view details' link this would fire a request to the server to fetch some HTML or JSON with details about the clicked item. Along with this request or rather the response, a server-side (invoked) event will return with the content.
Question/issue 1:
I'm unsure how to control the queue of events going to the server. They can ride along with user invoked events, but what if these does not occur, the events will get lost. I imagine having a timer setup up to send these events to the server in the case the user does not perform some action. What do you think?
Question/issue 2:
With regards to the responds, some being requested as HTML some as JSON it is a bit tricky as I would have to somehow wrap al this data for allow for both formalized (and unrelated) events and perhaps HTML content, depending on the request, to return to the client. Any suggestions? anything I should be away about, for instance returning HTML content wrapped in a JSON bundle?
Update:
Do you know of any framework that uses an approach like this, that I can look at for inspiration (that is a framework that wraps events/requests in a package along with data)?
I am tackling a similar problem to yours at the moment. On your first question, I was thinking of implementing some sort of timer on the client side that makes an asycnhronous call for the content on expiry.
On your second question, I normaly just return JSON representing the data I need, and then present it by manipulating the Document model. I prefer to keep things consistent.
As for best practices, I cant say for sure that what I am doing is or complies to any best practice, but it works for our present requirement.
You might want to also consider the performance impact of having multiple clients making asynchrounous calls to your web server at regular intervals.