Lets say you have a simple app that has a "create thing" button, and when you click it, you navigate to a new URL to edit that thing. Now lets say you don't want to have to wait for the server to allocate you an ID before you show the editing interface.
What would you do? Temporarily write "new" in the URL until an ID is available, and then swap it out? Allocate an ID on the client side and hope it doesn't collide with an existing ID? Either way you would need to stop Relay from fetching information that isn't really there yet. How would you do that?
Create a second route for the new state and give it a different Relay.Container that doesn't fetch any information about this object, perhaps.
I've accomplished it by passing the viewer directly to the mutation and modifying it right there.Unlike nodes fetch from relay, the newly created node won't have the dataID property on it thus you can easily identify it in your react component.
Related
I'm using Slack's modals + their new BlockKit interactive actions. I have a modal dialog with several section's that include select menu accessories. When one of those accessories changes (ex: user preference goes from Yes -> No), I want to update the modal's view to reflect the change in some contextual text.
The docs outline two ways to update a model. Because I'm not using the traditional modal inputs, I have to update the modal via the API and not via response_action. Proof: I don't even receive a view_submission payload at all... I receive a blockkit_action payload.
The docs conflict a bit. In the above link they say that to update a view you must pass in the returned ID of the view when it was opened:
Remember the view.id that was included in the success response when
you used views.open earlier? We hope you kept it, because you can now
use it to update that view.
But when you look at the docs for the views.open and views.update, it appears there is a second option: external_id. The views.update docs say this:
A unique identifier of the view set by the developer. Must be unique
for all views on a team. Max length of 255 characters. Either view_id
or external_id is required.
Initially I got everything working really nicely by choosing an external ID of myapp-mymodal-[userID]. But as soon as I tried opening the modal simultaneously on my Desktop + Mobile client, I started getting internal_error responses and have been unable to open the modal since!
So I started looking into saving the view ID, per the first quote. My problem is: that ID changes every time the modal opens. I don't understand how I am expected to possibly keep track of the 0-2 "active" view IDs that might be taking place across a user's Desktop + Mobile clients (or more than 2 if they have an iPad, a second laptop, etc).
I tried to look for some sort of unique client ID that I could either use to include in the external_id or in my view_id persistence logic, but given that Slack's API appears to be sesssion-less I couldn't find any such thing.
How do others solve this problem?
Try using the private_metadata field in the View
I initially did the same thing you did, which worked, but I wanted to avoid that edge case if possible. What I figured out, is that I could pass the external_id that I created when opening the view into the view's metadata, and then retrieve it when I receive an interaction.
When I set the external_id I set it to the userID + the current time (so it's always unique, even if the user opens the modal from different devices)
externalID := UserID + time.Now().String()
and pass that both as the external_id for the view, and as a string into the private_metadata.
PrivateMetadata string `json:"private_metadata"`
When the user interacts with one of my blocks and Slack sends me the interactive message, I retrieve the metadata like this:
Request.Payload.View.PrivateMetadata
I wrote my Slack app in Go, but I tried to make it clear for any language. Let me know if anything is unclear or needs expanding on - this is my first time giving back to the Stackoverflow community.
In my Rails App, I made a form_for to allow any visitor to submit their content.
But after submit, I want to ask user, whether they want to register for this site or not.
There are some approach to this:
Redirect after user submits the form, left the initial post anonymous.
Much the same as the first one. But somehow help user to reclaim the post they just make
Store the content in some place first and do not submit. Instead, ask for register. And after register, show the stored content before and ask user to submit again.
Basically, I can implement the 1st method. But it seems just not that good. For the 2nd and 3rd one, I do not know how to reclaim the post or store content beforehand.
Is there a standard way to do this? How can I solve this problem?
For solving the same kind of problem, I chose your 3rd option. For that you can use sessions, it will allow you to keep some information in memory related to a specific connection to your server.
http://guides.rubyonrails.org/action_controller_overview.html#session
There are some ways.
First of all you need to keep in mind that these are different behaviors from which you should chose first and do not let the implementation force you to chose one.
For the second case you can have the id of the post that was created (along with some guarantees that it is an orphan post) and then tweak your register method to also assign a post to a user after creating one.
The Third case can be implemented by storing the post data either to session or to a backend temporary store and retrieve them if needed.
I have a object that i want to store for a moment. The object is in a controller for now, the controller will generate a view. A AJAX request is made from the view to next controller. For that moment i need the object previously stored. Previously, i used session and it worked well. But not sure it is the right thing to do. Is session the answer for this or is there anything else?
I have used cache also.but as per the cache concept.It will access for all the users.So one user data will be override to another.So the cached object data will be change for the same user.I need to handle the data storage for an particular user(Independent).
How is it possible? anyother approach is there please share me.
In Controller I have used Httpcontext.cache["key"]=dataset;
but some one suggested like this.but its not displaying
Explain:
In Controller: httpcontext.current.cache is not coming.
HttpContext.Currenthandler and HttpContext.Currentnotification properties only coming.So How can we handle the temp data storage in MVC.
Please help me.
You could use TempData if you want to store data for the next request only. If data should be accessible between multiple requests, then use Session. Here is short explanation of each one with examples.
As Alex said you could use TempData but if you want to use the data in multiple request, you could use TempData.Keep("YourKey") after reading the value to retain the data for the next request too. For your Information TempData internally uses Session to store your data (temporarily)
I would recommend URL parameters for a HTTP Get, or hidden form fields for a HTTP Post, if this is short lived. This is highly about avoiding the session.
But if it should really persist, then a database might be a reasonable location. Imagine a shopping cart that you don't want to dump just because a session timed out; because you'd like to remind the user next time about items they still haven't purchased.
Why not use the session? I don't generally recommend using the session, as you could find yourself with a global variable that two different browser windows are manipulating. Imagine a glass. One window is trying to fill it with Ice Tea. Another window is trying to fill it with Lemonade. But what do you have? Is it Lemonade? Is it Ice Tea? Or is it an Arnold-Palmer? If you try to put too much stuff on the session, and overly expect it to just be there, you might create an application that is non-deterministic if heaven forbid a user opens a second window or tab, and switches back and forth between the windows.
I'm more ok with Temp Data, if you truly have no other options. But this is not for persisting data for more than a second. Temp data will disappear after the first request reads it, as in, it's meant for a very temporary usage.
I personally only use TempData if I have to do a redirect where I can't otherwise keep it with me, or if I need to have that data for say generating a PDF or image that is going to be called via a HTTP Get by a viewer on the actual page, and then only if the model data is too large for the GET url ( many browsers only support just over 2000 characters, which long description or many fields could fill up.)
But again, pushing items around in hidden form variables, or in url parameters can be safe, because you have no multiple window use conflicts (each carries around its own data for peace of mind.)
I am looking for a simple way to get data displayed in an issue as just plain text. Basically, I want to be able to type in a lookup id in the issue creation and then once the issue is created, it would call one of our web services to retrieve data connected with that ID.
This wouldn't be coming from another issue tracker, but rather straight from one of my databases.
What would be the easiest way of accomplishing this? I would like the workflow to be: Enter id #, hit save, see the data with that ID displayed in the ticket (Doesn't need to be editable, just displayed in the ticket view).
The easiest way is to create a workflow function that is triggered at Create transition to do the job. There your code can query information from the database and replicate them into JIRA standard and custom fields of the issue itself.
Then you can prevent edition of replicated fields by tuning Edit screen for your issues.
You can also use your function to update field content from time to time, either at transition or in a trigger.
An option is to create some read-only custom fields than query each piece information from the database. It will prevent data replication but it will be probably slow and it does not apply to default fields.
What want to be accomplished is:
I want to "synchronize web browsers". my site has a "wait URL" where when browser gets there it will be kept waiting till another browser also go there and then both will be presented with a quiz-like game.
Right now the wait url will call each second to Rails to check if other player came to the game. How can in the Rails framework detect a different client connecting to the same URL?
As the controller is recreated per request looks like is not the place, not the view for sure and storing this in the model looks really clumsy.
Also, after the pairing I need to check and compare every answer of the paired users so somehow that information must be retained
What you're trying to do is share information between users. So the database or memcached are the most sensible.
Simplest: I'd create an ActiveRecord object, perhaps called Quiz, instances of which people join by virtue of going to a URL, e.g using default routes:
http://yoursite.com/quizes/join/3434
You'd need an ajax poller poller to notify the others; use periodically_call_remote for this -- you could use render :nothing => true by default and render something else if there was an error to keep it efficient. You can also use the frequency method as a basis to determine whether people leave the quiz as well (e.g. if frequency is 1s, then assume someone has left if they didn't ping after 5-10s).
Assuming these users are not registered with the site so don't have some kind of user id you could store I would suggest using the session. It is a per user data store. By default the session is stored in an encrypted cookie on the users machine. However you can use ActiveRecord as the session store and could maybe query that table directly?
Store the URL in the session and do a search for it at a later time. You can normally only access the current users session using the Rails 'session' hash but maybe (untested) if you created a model called Session (or maybe something more specific like 'WaitingGamers') which used the sessions table you could lookup the information you need.
I would guess when using ActiveRecord as the session store the session data is stored as a serialised hash. Use Marshall to turn it back in to a regular hash and find the data you stored in there.
I'm not a rails expert, but since all the state resides in your database that would be the place to keep this information.
You could keep a "waiting users" table, and in the "wait URL" view check if the user is already in the table. If not, add him to the table. Then, check if there is another user waiting (maybe there's more than one?) and if so, match them up and delete them from the table.
Another improvement would be to keep a timestamp for each user in the "waiting users" table, which gets updated in the view - this would serve as a keep-alive that will enable you to detect users that left the "wait URL" page or closed the browser.