我想讨论一下我在React Web App中进行身份验证流程所遵循的范式，并且需要您的建议/建议。

该应用在右上角有一个按钮 有条件（基于用户的身份验证状态）。如果用户已登录，则按钮上显示嗨，名字，用户可以点击受保护的路线，只是一个登录按钮。

当前流量：

每次用户访问该应用程序时，都会在显示实际路线之前显示一个微调框，直到 Firebase的onAuthChanged（）检测到用户的身份验证状态为止，这需要花费几秒钟的时间。 onAuthChanged()传达了身份验证状态后，应用程序会根据身份验证状态使用右上角的按钮呈现路由。

当前流量问题：

以上提到，对于用户来说，流程并不像无缝体验。因为每次用户再次访问该应用程序甚至刷新其浏览器时，它都必须等待该烦人的微调器消失。这是一个糟糕的用户体验。

无论身份验证状态如何，大多数应用程序都可以进行交互，因此即使是公共路线，也无法在整个应用程序中显示微调框，因为仅需要知道身份验证状态为了有条件地渲染该按钮。此流程使该应用程序完全无法使用，直到Firebase未检测到身份验证状态为止。另外，由于所有路线都是延迟加载的，因此它会增加用户首次访问应用程序的时间，而第一个微调框会显示为后备，以便延迟加载路线第二个用于身份验证状态。

电流解决方案：

我已经想到了可以在上述方面为我提供帮助的解决方案。我现在想的是微调该按钮，直到 Firebase 检测到身份验证状态。这似乎是一个很好的整洁解决方案，因为当按钮闪烁时，现在使用的用户可以交互并浏览应用程序。

解决方案的缺点：

但是这个按钮实际上并不仅仅位于右上角，还带有其他三个按钮，它们链接到其他一些公共路线。因此，通过仅微调一个按钮，可以使UI完全不一致，因此我认为我可以对所有这四个按钮进行微调。但这对于用户来说似乎很烦人，整个应用程序在刷新时会快速加载，但是上方的4个按钮仍会闪烁几秒钟，并且无法访问其中任何一个来访问其他公共路线。

替代解决方案：

该解决方案有第三次也是最后一次迭代，在此，我正在考虑缓存身份验证状态，作为本地存储中的布尔值检查并没有名字。现在，在浏览器刷新和重复访问应用程序方面，该应用程序将变得毫无生气。

注意事项：

但是，假设用户已在其他设备上更改了他的名字，并且用户在此浏览器上访问了该应用，该按钮将在显示的旧名称中已缓存本地存储。要同步该名称，我必须将onAuthChanged()中的更新名称存储在本地存储中，从本地存储中更新 redux ，然后将其显示在按钮。现在，这似乎对用户来说是一个 bug ，并且可能还会报告，因为旧名称会闪烁几秒钟，直到更新的名称不是来自{ {1}}

结论：我想知道您的观点，或者您的观点是否比上述观点更好。谢谢！：）

如何在React Web App中处理身份验证流程？