I have these codes, if the user opens the form dialog for the first time, it works well.
function PostFormDialog({ id }) {
const queryClient = useQueryClient()
const post = useQuery(['post', id], () => fetchPost(id))
const update = useMutation(() => updatePost(formValue), {
onSuccess: () => {
queryClient.invalidateQueries(['post', id])
},
})
if (post.isLoading) {
return 'loading...'
}
return (
<Dialog {...dialogProps}>
<Form initialValue={post} onSubmit={update.mutate} />
</Dialog>
)
}
But when I submit the form once, I quickly open the dialog box again, and it will display the last data. The data is being retrieved at this time, but isLoading is false.
I want:
After opening the form dialog box, if the data is out of date, wait for the data to be loaded and display loading...
If you are editing the form, switching tabs may cause data to be retrieved, but loading... is not displayed at this time
This is hard for me. I can avoid it by using optimistic updates, but is there a better way?
Try playing around with react query options. For example:
useQuery(
["post", id],
() => fetchPost(id),
{ refetchOnMount: true }
);
After opening the form dialog box, if the data is out of date, wait for the data to be loaded and display loading...
if your PostFormDialog unmounts after it is closed, you can set cacheTime for your query to a "smaller time". It defaults to 5 minutes so that data can be re-used. If you set cacheTime: 0, the cached data will be removed immediately when you unmount the component (= when you close the dialog).
Every new open of the dialog will result in a hard loading state.
If you are editing the form, switching tabs may cause data to be retrieved, but loading... is not displayed at this time
loading... is not displayed because the query is no longer in loading state. The extra isFetching boolean will be true though, which can be used for background updates.
However, when populating forms with "initial data", background updates don't much sense, do they? What if the user has changed data already?
You can:
turn off background refetches with staleTime: Infinity to just load initial data once.
Keep the background refetches, and then maybe display a "data has changed" notification to the user?
Do not initialize the form with initialValue, but keep it undefined and fall back to the server value during rendering. I've written about this approach here
Related
I fetch my autocomplete suggestions from my db, and I do that whenever the input changes, the problem is my function triggers every time my value changes as well (because that triggers an input change I guess), which is really inefficient and causes a lot of network requests on rerenders, how can I prevent that ?
My code looks something like this.
const handleValueChange = (event, newValue) =>{
setValue(newValue);
}
const handleInputChange = (event, newInput) =>{
// Fetching and setting suggestions here
...
setInput(newInput);
}
<Autocomplete
value={value}
onChange={handleValueChange}
inputValue={input}
onInputChange={handleInputChange}
....
/>
I would say look into using the useEffect hook in combination with state. Something along the line of
const [suggestions,setSuggestions] = useState();
useEffect(()=>{ //fetch and set suggestions },[]}
then set the options in the autocomplete to the state you just set. Making sure you conditional render the autocomplete to not display before fetching is done.
{suggestions? (<AutoComplete.../>):("")}
I don't know if you can use this line for line, but at least in the right direction.
I have a MERN app which pulls data from a collection in MongoDB to render a timer component in the DOM. Currently in my collection, I have three timers titled first timer, another timer and even another. When I make a get request and run console.log(res.data), I see all the timers and their relevant data logged to the console. However, when I try to set state of timers using the useState hook, only the last timer is saved to state. Here is the code of my component:
function Wrapper() {
const [timers, setTimers] = useState([]);
const [title, setTitle] = useState('');
useEffect(() => {
axios
.get('http://localhost:3001/')
.then((res) => {
console.log(res.data);
res.data.map((timer) => {
let newTimer = (
<Timer title={timer.title} id={timer._id} time={timer.time} />
);
let allTimers = timers.slice();
allTimers.push(newTimer);
setTimers(allTimers);
console.log(allTimers);
});
})
.catch((err) => {
console.log(err);
});
}, []);
Here I am making my get request and mapping through the res.data to create a new timer component for each iteration. Then, I make a copy of timers (since state is immutable), push my new timer to allTimers variable and finally run setTimers(allTimers). Here is what React renders:
I expect allTimers to contain one, two and then all three of the timers in my database when logged to the consol on line 17. However, only the most recent timer shows up so it seems like I am setting state incorrectly but I'm not sure how. Anyone have any suggestions?
Because you set useEffect to Only runs on initial render, it always refers to the initial state of timers, which is an empty array, and even as you try to update it with useState but on the next loop it still refers to the empty array. The only update to have real effect is the last one, pushing the third timer into the empty array.
You can move your entire map loop to the return statement of the functional component to render an element for each timer.
I have latest enterprise React agGrid table with Master/Detail grid. My data is fetched on the client every 5 seconds and then put immutably to the redux store. React grid component is using deltaRowDataMode={true} props and deltaRowDataMode: true in Detail options.
My master grid performs normally as expected: if I have range selected, grid would keep selection after the data updates, so would filters and visibility menu would be still opened. But Detail grid behaves differently: on data refresh selections are being removed, visibility menu closes and grid jumps if filters were changed.
I've read in docs that when I open Detail grid it's being created from scratch, but in my case I don't close Detail. Anywhere I've tried keepDetailRows=true flag, which solved problems with jumping on update and selection loss, but Detail grid doesn't update data now.
It seems there are only two possible options according to the docs https://www.ag-grid.com/javascript-grid-master-detail/#changing-data-refresh. The first one is a detail table redraws everytime a data in a master row changes and the second one is a detail row doesn't changes at all if a flag suppressRefresh is enabled. Strange decision, awful beahviour...
Update.
Hello again. I found a coupe of solutions.
The first one is to use a detailCellRendererParams in table's options and set suppressRefresh to true. It gives an opportunity to use getDetailGridInfo to get detail-table's api.
While the detail-table's refreshing is disabled, using detailGridInfo allows to set a new data to a detail-table.
useEffect(() => {
const api = gridApiRef;
api && api.forEachNode(node => {
const { detailNode, expanded } = node;
if (detailNode && expanded) {
const detailGridInfo = api.getDetailGridInfo(detailNode.id);
const rowData = detailNode.data.someData; // your nested data
if (detailGridInfo) {
detailGridInfo.api.setRowData(rowData);
}
}
});
}, [results]);
The second one is to use a custom cellRenderer, wicth is much more flexible and allows to use any content inside a cellRenderer.
In table's options set detailCellRenderer: 'yourCustomCellRendereForDetailTable.
In yourCustomCellRendereForDetailTable you can use
this.state = {
rowData: [],
}
Every cellRenderer has a refresh metod which can be used as follow.
refresh(params) {
const newData = [ ...params.data.yourSomeData];
const oldData = this.state.rowData;
if (newData.length !== oldData.length) {
this.setState({
rowData: newData,
});
}
if (newData.length === oldData.length) {
if (newData.some((elem, index) => {
return !isEqual(elem, oldData[index]);
})) {
this.setState({
rowData: newData,
});
}
}
return true;
}
Using method refresh this way gives a fully customizable approach of using a detailCellRenderer.
Note. To get a better performance with using an immutable data like a redux it needs to set immutableData to true in both main and detail tables.
OpenUI5 newbie here. I am trying to use OpenUI5 fragments, much like shown in the Walkthrough example, Step 16, in the documentation. I have a problem seeing how this can work properly.
The code below is a copy and paste from the Walkthrough example, Step 16, in the documentation:
onOpenDialog : function () {
var oView = this.getView();
// create dialog lazily
if (!this.byId("helloDialog")) {
// load asynchronous XML fragment
Fragment.load({
id: oView.getId(),
name: "sap.ui.demo.walkthrough.view.HelloDialog"
}).then(function (oDialog) {
// connect dialog to the root view of this component
oView.addDependent(oDialog);
oDialog.open();
});
} else {
this.byId("helloDialog").open();
}
}
Since the HelloDialog fragment is loaded asynchronously, it is clear that the onOpenDialog function may return control to the user before the dialog has been created and opened. It is in the nature of asynchronous calls that we must not make any assumptions about how long it will take until the asynchronous code is executed. Anything is possible. Therefore, we must allow for the possibility that the user has control over the web page for any amount of time before the dialog shows up, say, several seconds. What is the user going to do? They're going to click the button for opening the dialog again, and again, and again, thereby creating the dialog multiple times, subverting the intended logic of the code. To be honest, I am not sure if I would be comfortable having that kind of thing in my code. How should I deal with this?
in general, you're right, the dialog could take time to load but usually, the process takes a fraction of time and the user should not see any "loading" time.
This is possible only if your dialog load data asynchronously too.
If you really want to be sure to give graphical feedback to the user you could do like this:
onOpenDialog : function () {
var oView = this.getView();
// create dialog lazily
if (!this.byId("helloDialog")) {]
// set the view to busy state
oView.setBusy(true);
// load asynchronous XML fragment
Fragment.load({
id: oView.getId(),
name: "sap.ui.demo.walkthrough.view.HelloDialog"
}).then(function (oDialog) {
// remove the busy state
oView.setBusy(false);
// connect dialog to the root view of this component (models, lifecycle)
oView.addDependent(oDialog);
oDialog.open();
});
} else {
this.byId("helloDialog").open();
}
}
I'm attempting to create a logout page that will work even after that element has been attached once to the DOM. This occurs when you get a login, then logout, then login again, and attempt to log back out.
For instance, the shell has
<iron-selector selected="[[page]]" attr-for-selected="name">
<a name="logout" href="[[rootPath]]logout">
<paper-icon-button icon="my-icons:sign-out" title="Logout" hidden$="[[!loggedIn]]"></paper-icon-button>
</a>
<a name="login" href="[[rootPath]]login">
<paper-icon-button icon="my-icons:sign-in" title="Login" hidden$="[[loggedIn]]"></paper-icon-button>
</a>
</iron-selector>
<<SNIP>>
<iron-pages selected="[[page]]" attr-for-selected="name" fallback-selection="view404" role="main">
<my-search name="search"></my-search>
<my-login name="login"></my-login>
<my-logout name="logout"></my-logout>
<my-view404 name="view404"></my-view404>
</iron-pages>
I also have an observer for page changes in the shell:
static get observers() {
return [
'_routePageChanged(routeData.page)',
];
}
_routePageChanged(page) {
this.loggedIn = MyApp._computeLogin();
if (this.loggedIn) {
this.page = page || 'search';
} else {
window.history.pushState({}, 'Login', '/login');
window.dispatchEvent(new CustomEvent('location-changed'));
sessionStorage.clear();
this.page = 'login';
}
}
This works well as when I click on the icon to logout, it attaches the my-logout element just fine and performs what in ready() or connectedCallback() just fine.
my-logout has
ready() {
super.ready();
this._performLogout();
}
The issue comes when, without refreshing the browser and causing a DOM refresh, you log back in and attempt to log out a second time. Since the DOM never cleared, my-logout is still attached, so neither ready() nor connectedCallback() fire.
I've figured out a way of working around this, but it feels very kludgy. Basically, I can add an event listener to the element that will perform this._performLogout(); when the icon is selected:
ready() {
super.ready();
this._performLogout();
document.addEventListener('iron-select', (event) => {
if (event.detail.item === this) {
this._performLogout();
}
});
}
Like I said, it works, but I dislike having a global event listener, plus I have to call the logout function the first time the element attaches and I have to listen as the listener isn't active till after the first time the element is attached.
There does not appear to be a "one size fits all" solution to this. The central question is, "Do you want the parent to tell the child, or for the child to listen on the parent?". The "answer" I came up with in the question works if you want to listen to the parent, but because I don't like the idea of a global event listener, the below is how to use <iron-pages> to tell a child element that it has been selected for viewing.
We add the selected-attribute property to <iron-pages>:
<iron-pages selected="[[page]]" attr-for-selected="name" selected-attribute="selected" fallback-selection="view404" role="main">
<my-search name="search"></my-search>
<my-login name="login"></my-login>
<my-logout name="logout"></my-logout>
<my-view404 name="view404"></my-view404>
</iron-pages>
Yes, this looks a little confusing considering the attr-for-selected property. attr-for-selected says, "What attribute should I match on these child elements with the value of my selected property?" So when I click on
<iron-selector selected="[[page]]" attr-for-selected="name">
<a name="logout" href="[[rootPath]]logout"><paper-icon-button icon="my-icons:sign-out" title="Logout" hidden$="[[!loggedIn]]"></paper-icon-button></a>
</iron-selector>
it will set the <my-logout> internally as the selected element and display it. What selected-attribute="selected" does is to set an attribute on the child element. If you look in the browser JS console, you will see that the element now looks like
<my-login name="login"></my-logout>
<my-logout name="login" class="iron-selected" selected></my-logout>
We can define an observer in that in the <my-logout> element that checks for changes
static get properties() {
return {
// Other properties
selected: {
type: Boolean,
value: false,
observer: '_selectedChanged',
},
};
}
_selectedChanged(selected) {
if (selected) {
this._performLogout();
}
}
The if statement is so that we only fire the logic when we are displayed, not when we leave. One advantage of this is that we don't care if the element has already been attached to the DOM or not. When <iron-selector>/<iron-pages> selects the <my-logout> the first time, the attribute is set, the element attaches, the observer fires, the observer sees that selected is now true (as opposed to the defined false) and runs the logic.