Check for WebLN provider first

[MoritzKa]

Super useful starter template!

To benefit even more from WebLN I suggest checking for WebLN support first before showing some fallback options (QR codes, copy invoice, etc).
here is some example code for this feature. https://www.webln.guide/building-lightning-apps/best-practices#prioritize-webln-offer-fallback-options

Several wallets already support WebLN: Alby, BlueWallet, Blixt, Breez and its support keeps increasing. All their users can interact programmatically with lightning apps without QR codes.

[zeSchlausKwab]

Hey, thank you for your feedback.
I don't see QR codes (and mobile wallets) as a fallback. I think QR codes will be a big part of the picture and i like the idea of people scanning things to authenticate themselves and transact seems like nice UX.
Can you point to an example of how UX works with Breez or any mobile wallet that implements WebLN? Do they have a built in web browser?

[MoritzKa]

QR codes are an efficient way to exchange information across devices, indeed. But QR codes are only one-way communication (from the website to the wallet). The wallet does not communicate back. With WebLNn web apps can get the preimage as a return value (e.g. to validate the payment without permissions to connect to the node). Or it can request an invoice from the user.
In the digital world to exchange information displayed in the browser we don´t need them. You can leave it to some JS code (i.e. WebLN) to exchange invoice data or signatures for payments and authentications. The less user interaction required the less can go wrong (e.g. resolution of QR codes, bad cameras, etc.).
regarding mobile wallets: BlueWallet and Breez have a browser to open apps. You can try to open Wavlake in Breez and open Wavlake in the mobile browser of your phone. Wavlake checks for a WebLN provider first and can keep its design and UX experience because it does not need to show a QR code that is displayed across the whole screen.