If the view which serves for creating an item contains some dropboxes / checkboxes / whatever with values from the server, should it send separate requests for filling up those controls with values (one request per each collection of data) or it is better to have a single api endpoint that returns all of the necessary data for filling up the form on front-end?
For the sake of simplicity, I've simulated here an example: Say we're building an app for a car servicing company where clients can make appointments:
Should the front-end app make 2 get requests to api/models and api/services, or these collections can be returned from the server in a single response (from api/appointments/createformdata), What are the best practices regarding to this?
Thank you in advance!
Well, since in your example, both combo boxes need values, then I would load up on first page load. There would be no need for separate requests unless those combo boxes are dependent on data in the form, and then in that case you have no choice but to wait for user input to determine that.
so, say you have two combo boxes, and the 2nd one is cascaded by the 1st combo choice? Well, the first combo box does not change - so load it up at page load time, and you have to do that anyway. No use writing out separate events or code to load that first combo that MUST be loaded in the first place.
however, the 2nd combo box? Well, since its values are based on the first one, then once again, you have no choice, do you?
So, I don't see any real use case, that if two combo boxes are independent to each other, then I see next to no reason why separate requests would be required, and that just loading up both combo boxes on first page load would not suffice here? (then you don't need ANY separate requests).
Now, if there is some kind of tab, or UI and the user can't see nor use the combo boxes right away, or may never even select say some tab out of a tab control? Well, ok, in that case then you speed up the page load by not filling out the combo boxes until such time the user gets to that part of the form (maybe some pop dialog, or maybe some kind of wizard steps).
But, once again, if the two combo boxes are not dependent on each other? Then I see no reason to use two requests or events to load up both of them. But then again, it would beg the question as to how you did in the past load up the combo boxes anyway?
I mean, if each combo box was some ajax call, then keep using two of them, and keep the two requests. Since attempting to merge, or put two ajax calls that fill out two combo boxes as one call is a pain, and does not follow a re-use design patter. The result is messy code, and worse force you to write code that does two things.
I mean, if you build a nice general routine to call + fill out the combo box, then continue to use that code to fill out the 2nd one. I would not blow up really nice working code to somehow fill out two simple combo boxes on a page and attempt to use one request for that filing out of the combo boxes.
And as I stated, if the combo boxes are in plain view from the start of the page load, then code behind on first page load is the place to do this unless some rather huge performance issue were to crop up. As a result, you now don't have ANY separate requests to fill out the combo's, do you?
But then again, a combo box is good for what, 30, maybe 50 choices tops, and after that, you need a different UI, and thus once again, you don't have a problem performance wise by doing this either way, do you?
And if you are trying to fix or avoid a performance problem? Then you putting too many choices into the combo box, and that is the wrong ui choice, and then once again, you don't have this issue, do you?
I just started developing a test automation for an iOS app using Appium. I have to click several buttons in the app one after another with different XPath/Accessability ids.
I wondered, when to use the wait.until(ExpectedConditions.visibilityOf Element) expression.
Example:
wait.until(ExpectedConditions.visibilityOfElementLocated(By.xpath("//XCUIElementTypeApplication[#name=\"app\"]/XCUIElementTypeWindow[1]/XCUIElementTypeOther/XCUIElementTypeTabBar/XCUIElementTypeButton[3]")));
Should I check every time before I click a button if this button is actually visible or existing on the current state of the app or is this just unnecessary and time-wasting?
In my opinion, you should use ExpectedConditions in two case:
Screen load takes long, so you not ending up trying to click something that has not loaded yet. If you find your tests flaky (sometimes pass some times fails) then this probably the main reason why it happens
If you have something like ajax on your screen you want to make sure the data is changed on the page. (Example is you created a post on Facebook, and want to make sure content displayed)
I am writing an application in Meteor with React. I am trying to achieve an infinite scroll feature.
What I am doing is subscribing to a publication with a limit which is tracked by my component's state. When the component detects that it has reached the bottom, it increments the limit in its state.
This triggers a re-render and a subscription to more data.
The issue I have is the whole component being re-rendered. It loses scroll position and takes you to the top.
How do I achieve infinite scroll with pub/sub based on the limit saved in state and only adding extra rows in the component instead of rendering the whole thing?
Subscribing to the whole list with no limits is not an option for me
So, I couldn't find a way to do it with pub/sub so I had to use Meteor.call, that does a mongo's skip() and limit() based on a page to fetch data from the database and then save that data in the component's state.
This way it does not re-render the entire thing but only adds nodes for the new data it receives.
This also means there is none of the automatic socket stuff happening, which is fine for my use case.
One benefit I do get is it's easy to know whether there is more data left in the database to fetch. Surprisingly tricky with pub/sub unless you add a package.
You have to store your data in some stack and enlarge it. React will render only new elements of your stack instead of re-rendering whole component.
Question 1:
I have to verify keyboard actions for my web application. Any inputs on how to perform keyboard actions using robot framework would be helpful.
Question 2:
Scenario: There are 500 items in the list which can be selected by using checkbox. I have written a script to select 25 items using loop, it worked. Same script doesn't work when it is configured to 40 items. Looks like only 27 items in list are accommodated in page. Next page with items are fetched only as we scroll down or Page down is pressed in keyboard. Scroll bar/scroller is not an identifiable element, so couldn't perform scroll operation using script. So, I thought of performing two operations(Selecting checkbox and Page down) in a loop. Kindly suggest any inputs to perform this...
Press key keyword is useful for your task.
Refer here for complete details.
So I have C# function that's gathering data results and images and uploading them to the SQL Database.
What I'd like to do is create a progress bar showing the progress through this function(by like incrementing the bar 1/NumOfLoops each pass of the outer most loop).
I was hoping to just use a DIV with changing width as my progress bar, stuck in an update panel.
The issue of course is triggering the update panel to update.
Or is there a better way to go about this?
Yes, this is possible, but you may not the like the solution I link you to, because it involves using an iFrame.
Read Easy incremental status updates for long requests for details on how to use JavaScript to create an iFrame that hosts your long running process .aspx page and then have that page stream back its progress.
Note: In the example, the progress values are streamed back and reported via the text of the button, which is disabled while the long-running process does its work.