I tried shortening the timeout to 500ms and performed some tests. I found that the selection strategy doesn't slow down the user's startup experience; instead, it might make it faster. The user's actual complete loading occurs when the "loading" state disappears, which is loadCashtabState in useWallet.ts. Through adding a timer for simple testing, taking my Hong Kong IP as an example, useWallet.ts:969 shows Cashtab startup duration: 2583ms. This is the time actually perceived by users. However, when using the "selection strategy" and changing the timeout from 1000ms to 500ms, the test result is 620ms for Cashtab startup duration. Therefore, finding a faster node within 500ms and establishing a connection is often faster than choosing a default one. Furthermore, this 500ms could potentially be adjusted to 400ms or 300ms, meaning "if we can't find a faster node within 300-400ms, it doesn't matter anymore." WebSocket connection establishment speed is 2-3 times that of ping, and it's easy to prove through testing that lower WebSocket latency means lower query latency.

My view is that this approach is worthwhile.

rebuild again :-) please

Add test for manual close

@bot preview-cashtab

Add README.md and npm version patch

Removed the previous delay handling. Only ensure in this diff that faulty nodes can be switched correctly.

Based on offline discussions,
Joey's view is correct. "A node that can establish a WebSocket connection (_websocketUrlConnects) but immediately throws onerror or onclose after connection" was inferred from a March failure,

“A node that can establish a WebSocket connection (_websocketUrlConnects) but immediately throws onerror or onclose after connecting,” is not an accurate description; it’s more of an extreme example.

This diff will only address the issue of _websocketUrlConnects not closing the WebSocket under timeout conditions.

keep the first modification to close WS

Extra comments and trailing whitespace removed

update README.md

update README.md and npm version minor

Better test url orders

Some minor adjustments regarding the above.

add package-json

rebase and add test

add test, in the test, i don't mock measureWebsocketLatency, but instead use asynchronous actual testing to
keep it simple.

Keep using Infinity, adjust the output to display in ms

Directly return -1 in measureWebsocketLatency for timeout cases

Based on what was mentioned earlier, I first moved appendWsUrls out of the class in D17935 and reused it here.
Additionally, I removed the concurrent and batch settings, and optimized and streamlined the Sort function (the
original sort function considered multiple rounds of testing, making the code more complicated)

// Using the static method with strategy
const chronik = await ChronikClient.useStrategy(

ConnectionStrategy.ClosestFirst, 
urls,
maxConcurrentTests // optional parameter, default is 20

);

Node selection is implemented using static methods in chronikclient while maintaining consistency with existing methods. Removed the original npm list
test. Moved measureWebsocketLatency and sortNodesByLatency to chronikclient.ts

After this modification, it no longer dynamically selects the best node. Instead, it rearranges the
node order only once during initialization. Removed the URL string and kept only the array to maintain consistency with chronikclient.
And use as-order as default

After this modification, it no longer dynamically selects the best node. Instead, it rearranges the node order only once during
initialization. Removed the URL string and kept only the array to maintain consistency with chronikclient.

I have tested the modified chronik-client locally and it switches smoothly. Perhaps I could deploy it on an actual test domain for public testing?

--update D17815

Switch to my branch and commit again.

Completed the above modifications

In D17815#406034, @bytesofman wrote:

would be a good change and help to get some of the css more standardized in Cashtab

[Cashtab] Introduce CSS variables to make styling easier

An attempt to resolve a missing base commit

[Cashtab] Add click-outside-area closing effect for NavWrapper using event bubbling

lint

remove stopPropagation

Updating D17756: [Cashtab] Add click-outside-area closing effect for NavWrapper using event bubbling

Squashed commits as requested and removed unnecessary useEffec

In D17756#404509, @emack wrote:

Implemented a click-outside closing mechanism for the settings window

where is this implemented? I'm not seeing event bubbling above, only the removal of the redundant useEffect.

Remove useEffect