I use date pickers in my app and till the update of RN to 0.63 they were working fine. Date picking in the 'date' mode was done on iOS by means of selecting values on 3 vertically spinning "drums" : the date, the month and the year. Now after the update it looks like this :
This is what a user sees instead of the "drums". The area is not spinnable nor swipable and only responds to a click on the highlighted date.
This is what a user sees after a click to the highlighted date
It kind of works but offers an extremely convoluted UX. I wonder if this is a "new norm" or is there is a way to configure/hack an underlying native component in order to revert to previous behavior. The exact component I am using is xgfe/react-native-datepicker. I also tried to switch to a newer #react-native-community/datetimepicker, but the result is roughly the same with this strange intermediate control opening first and if clicked - opening a calendar modal.
I just figured out the #react-native-community/datetimepicker exposes a "display" property for IOS (possible values: 'default', 'compact', 'spinner', 'inline') which determines which exact UI driver to use. The 'spinner' renders the mentioned 'drums' that every IOS user is accustomed to, the 'inline' renders a calendar. I assume that 'default' can differ, but in my case it yielded the same result as 'compact' which is what you can see above. Apparently in the older RN components which do not expose such property the default driver will be used possibly resulting in all sorts of inconveniencies.
Related
Has anyone had any luck in figuring out how to use the react library https://react-day-picker.js.org/docs/input/
With Capybara/Selenium? Unfortunately it doesn't allow simply typing in the text such as MM/DD/YYYY like most date-pickers. This only allows mouse selection.
Or is specifically setting the value basically the only way to do so?
Without an example which shows the actual configuration of react-day-picker you're dealing with it's impossible to say exactly what you need to do, but the general rule is if you are testing the sites functionality then do what a user would need to do. In your case that may mean click on the forward/back month arrows until you get to the desired month, then click on the specific day element. Assuming the date you want to select is in the future (September 20, 2019) it would be something like
caption = find('.DayPicker-Caption')
until caption.has_text?('September 2019', wait: 0) do
current_month = caption.text
find('.DayPicker-NavButton--next').click
# wait for month to change
expect(caption).not_to have_text(current_month)
end
find('.DayPicker-Day', exact_text: '20').click
If you're not actually testing functionality (web scraping, etc) then you can use execute_script to call the react-day-picker JS API and set a specific date.
Today I have upgraded from Vaadin 11.0.2 to 12.0.0 - Everything went smooth, except one thing:
In a grid of mine where I have a rendered column to show a ComboBox, there is a strange issue with the ItemLabelGenerator. I defined it as follows:
grid.addColumn(new ComponentRenderer<>(gridItem -> {
ComboBox<MyObject> comboBox = new ComboBox<>();
comboBox.setItems(myObjectsService.findAll());
comboBox.setValue(gridItem.getMyObject());
comboBox.setItemLabelGenerator(MyObject::getName); // MyObject::getName returns String
// comboBox.addValueChangeListener omitted
return comboBox;
}))
.setHeader("MyObject")
.setId("myObject");
This has been working fine in Vaadin 11.0.2 but now the item-labels are displayed as package.path.to.myobject.MyObject#41d8d522 and not the actual name of gridItem.getMyObject();
When I click on the ComboBox to show all options, the labels are correct! but as soon as I select one, it turns into the aforementioned wrong string.
Important detail: for testing reasons I have now added a similar ComboBox with the same setup into a simple VerticalLayout (AKA not in a grid), and there everything works perfectly fine. That is why I think the issue is with the ComponentRenderer somehow and not with the ComboBox alone.
Is this a bug, or have I missed something when upgrading to 12.0.0 ?
In the vaadin blog post about the new release of Vaadin 12, I see that there is one known breaking change, and it has to do with ComboBox:
If you are coming from Vaadin 10 or 11, you should update the platform dependency in your project build file. The only breaking change we introduced was because ComboBox now supports server-side lazy-loading. If you are using filtering with a ComboBox see instructions on fixing the possible compilation issue.
However, no filtering whatsoever is involved in my case.
This answer was written by Diego Sanz Villafruela in the Vaadin Forum, where I raised this exact issue too.
I created an example similar to yours and I discover that the order in
which you set the value and the ItemLabelGenerator matters.
You should put comboBox.setValue after setting the
comboBox.setItemLabelGenerator.
Otherwise the method String.valueOf(obj) will be called the first
time, giving you the object's representation (MyObject#41d8d522) and
not the name.
I have an app that from some reason needs to assign a custom date to the user contacts, The app was out and worked fine. Now I wish to build a swift version of the app.
While testing it on xCode 6, iOS7 + 8 everything looks great, but when testing in a device I see that the date is added as the Anniversary date of the user and without my custom label.
I tried to add the date directly in the native Contacts app and found that new contacts does not have an option to add a custom date.
Testing on Yosemite I still find this option available.
When checking the ABPerson API I found that the API still has the kABMultiDatePropertyType
// Dates
AB_EXTERN const ABPropertyID kABPersonDateProperty;
// Dates associated with this person - kABMultiDatePropertyType
It is important to note that when saving the new date I do not get any Error and the date is saved but without my custom label which is important as I do not want to override the user Anniversary date.
Any idea why this is happening / any workaround ?
I have a large XPage with about 170 fields on it. I have tooltips for a fair number of the fields. The tooltip does a lookup into a help DB and returns the related text. They work fine but they significantly slow down the load process because of the number of times the lookup is performed. I put a dBar.info statement in the JS that loads the text and in one load the document and put it into edit mode it would appear to have fired that one tooltip lookup 6 times. If it does that for every one of the tooltips then clearly that is the reason for the slow performance of the XPage. I did it both with the DynamicContent set to both true and false with similar results. I'm tempted to just remove the tool tips but that kind of defeats the purpose.
Is there a way to limit the tooltip to only fire the lookup when called? Like something linked to the MouseOver event. It seems to me the tooltip in the extension Library works OK if there are only a few fields requiring inline help but does not scale well.
Just as a test I removed all the tooltips from the XPage and while the loading is slow it is probably acceptable, but the tooltips slow it to the point of unacceptability.
Bill,
This is an excellent use case for an ApplicationScope bean. Create a bean that implements Map and uses an internal HashMap as cache. Let's call it tooltip. In your tooltip you define the label as EL e.g. tooltip['Manager']. XPages will call the get function. In it you check the internal HashMap if you have the value, otherwise you look it up. So lookup happens once only.
You could instead of looking up on demand opt for loading when initialized. Using a view navigator that should be very fast. Since it would be an Application scope only loaded once.
Makes sense?
You can use view.isRenderingPhase() to minimise the lookups during a partial refresh. With the tooltip you can also change the showDelay property so the tooltip has a delay before showing. This is a good thing to do for a view, so it doesn't try to load each tooltip as the mouse moves down the page. dynamicContent="true" may also mean it's not loaded with the page, but only when called - I haven't checked this so I'm not certain.
My program flow requires that I first set the value of a select option in the Viewmodel and then I load the available options into the Viewmodel. This causes problems, typically the first available option will be seen in the selection list after this, while the selected option value stays at the specified value.
I was hoping that setting the new "valueAllowUnset" would help, but instead my page becomes unresponsive when using it.
Therefore I currently set the original value again after loading the options. Strangely, this only works when I set the value, set a different value and then set the value again, e.g.
self.data()[field](orgValue);
self.data()[field]({});
self.data()[field](orgValue);
(I store values for multiple selection lists in the self.data observable and access them with the property index "field".)
I tried to strip this down to a simple JSFiddle (http://jsfiddle.net/timvdh/HN6DE/), but the behavior does not show there, although the example pretty much resembles my actual application. However, I am using about 30 select lists there.
So I was hoping, that someone can make an educated guess about what goes wrong in my application, I am hoping that the fact that I have to set the original value three times maybe gives a clue.
EDIT: This fiddle demonstrates, that setting the selected option before and after filling the options list does work with "valueAllowUnset": http://jsfiddle.net/timvdh/HT5Tp/
I am using JQuery Mobile with knockout.js and that caused the problem (sorry I did not even think about JQM being the problem in the first place). I am now setting the option before filling the list and after filling the list I call
$("#selectmenuID").selectmenu("refresh");
to display the option.
The hanging browser was not caused by knockout, there are additional subscriptions to the selectmenus in my app. "valueAllowUnset" changed the behavior of the selectmenus and triggered loops caused by problems in my code.