The changes made in this pull request are quite extensive, and the
proposed solution is briefly described in the following text. I hope you
can take some time to review it when you have a moment.
**What did I modify in this branch?**
Perhaps you have noticed that we have been using the skeleton screen
technology on the frontend pages. However, the control over it seems a
bit simplistic. We currently only initiate the skeleton screen when
entering the page and directly replace it with new nodes upon interface
returns. As a result, there is a "skeleton screen flickering" issue
during usage. In favorable network conditions, we often observe a quick
flash of the skeleton screen. From a user experience perspective, I
prefer the page not to change so rapidly. Therefore, I have submitted
this pull request to address the issue.
**How did I make the modification?**
Through code comparison, it can be observed that I actually encapsulated
a new hook named `useSkeletonControl`. The parameters it returns are as
follows:
```ts
{
isSkeletonShow, // Should the skeleton screen be displayed?
openSkeleton, // Activate the skeleton screen.
closeSkeleton // Deactivate the skeleton screen.
}
```
In the code logic, you can see that I have implemented a delay-like
operation for both activation and deactivation. The reason behind this
is that I believe the opening logic of the skeleton screen should be
like this:
- When the interface returns within 1 second, there is no need to
activate the skeleton screen.
- When the interface takes more than 1 second to return, the skeleton
screen is activated, and the activation time should not be less than 3
seconds.
(The above-mentioned times are all defined as constants and can be
adjusted according to the actual situation.)
Based on this design approach, I utilized `setTimeout` and
`clearTimeout` to control the timing of activation and deactivation.
Why provide a `needShowFirst` parameter?
Clearly, this parameter is used to control whether the skeleton screen
is rendered right from the start. It allows the skeleton screen to
bypass the first timing condition mentioned earlier, meaning it can be
activated even if the interface returns in less than 1 second. The
reason behind this is that I noticed in some pages, the skeleton screen
needs to occupy its position right from the start to prevent the
'flickering' issue on the page. So, I introduced this parameter.
However, in my design, I don't intend to show the skeleton screen when
the interface response time is too short, as it might negatively impact
the user experience.
The above is the reason behind my pull request. I have made
modifications for the pages I identified, and I hope they will be
accepted. Additionally, if there are better solutions, I am eager to see
them. Thanks again for considering my changes.
---------
Co-authored-by: LinkinStars <linkinstar@foxmail.com>
Co-authored-by: robin <robin@rnode.me>
easy
e529d33dbf