Martinsos
commented
1 month ago @sodic @infomiho you pplz are right! I didn't want to go too much into design for two reasons:
- Wanted to first hear if the whole idea makes sense.
- It would be quite bigger change and I wasn't sure if we want so much code for a "minor" thing like this.
But the idea you pplz mentioned, I have been thinking about it while coding this also. And it is a better, more scalable way to do stuff like this. So ideally, instead of pushing messages like this into the generated code, we would have some kind of a visual thing in the app itself that is able to display warnings / error and similar.
Solution could be whole wasp studio, that runs in another tab, with logs, messages, app overview, ... . But that is far away, and would still not be enough "in your face". So while I think we should have that in some way, it wouldn't solve this particular problem of informing them right now.
What would be faster and possibly complimentary solution is something that is our dev tool thing that is rendered as part of the app, and shows warnings, errors, ... . I wrote about this some time ago here: https://github.com/wasp-lang/wasp/issues/250#issuecomment-1699037784 , idea was some kind of small popover that communicates basic stuff. This is probably similar to the Astro's dev toolbar @infomiho (I haven't used Astro)?
Ok, so I suggest following then:
- I will close this PR, it feels too much work to make this pretty compared to doing it in more scalable way right away.
- I will create another issue, which will be for creating a very first version of Wasp's dev toolbar, that will be rendered in the app in a minimally disruptive way, and will for start be able to just show messages (errors, warnings). We will then make the first usage of it for this notification about Dummy provider.
This will be an interesting experiment that will quickly bring value, and later as Wasp Studio evolves, we can figure out how to make those two work together or merge them.
sodic
infomiho
This PR was inspired as a possible solution to https://github.com/wasp-lang/open-saas/issues/137 -> give it a read, it is important for the context.
Result is this, upon successful signup:
I could have added the same thing for other email auth forms (password reset, ...) but felt that might be a bit much.
I am not even sure about this. It seems to me like it will help people on the happy path, when they are creating their first account, and can't find that email in the email. Solution can also be just making it clearer in the docs, putting warnings about it in the right place, and that might be enough. For example, once they are ready to start doing something with their open-saas app, we can mention in the guide that Dummy provider is used and they will not receive emails.
But I wanted to try this. At the end, this is the best way to inform the dev.
The problem is, there are other situations where Dummy provider might surprise them, e.g. if job is sneidng email or something. And we have no warning in that case. We just can't in every case inform them about this. Nor should we , it would be annoying. So I though ok, this is "entry point" and likely if they will get confused, it will happen here, so we can teach them here.
I am ok with dropping this PR if we conclude it is more harm then good, but if others like it, we can merge it.