New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LPS-116254 Localization - alert success notifications are not displayed correctly #78
Conversation
To conserve resources, the PR Tester does not automatically run for every pull. If your code changes were already tested in another pull, reference that pull in this pull so the test results can be analyzed. If your pull was never tested, comment "ci:test" to run the PR Tester for this pull. |
ci:test:sf |
✔️ ci:test:sf - 1 out of 1 jobs passed in 14 minutesClick here for more details.Base Branch:Branch Name: master Sender Branch:Branch Name: LPS-116254 1 Successful Jobs:For more details click here. |
Jenkins Build:test-portal-source-format#2947 |
ci:test:relevant |
Jenkins Build:test-portal-acceptance-pullrequest(master)#7732 |
Sounds like we should just change I looked to see if we had any Lexicon guidance on how toasts should behave in the presence of multiple simultaneous ones, but couldn't find anything here), but this sounds to me like something that would be desirable for it to define. cc @drakonux Separate topic is your fix here of changing the ID:
Given that the number of these other call sites is small (2), I think it would make sense for them to be somehow made compatible. If we do implement stacking in At least in util-taglib, we could just depend on React directly, because it is an OSGi module. The portal-web/docroot thing would require us to be a little more creative, but we could still probably figure something out. |
Ideally, Toasts should stack, we should trigger Toasts inside
I believe that the second option could generate more complications than that, so maybe the first option would be easier ?! |
Sounds good. @diegonvs, do you want to take a shot at refactoring this to get |
I can do. If I catch any limitation I can post here. |
Updated. Now, ToastContainer is created manually when not receiving Now We're able to stack(when calling multiple times) using openToast when: passing I used metal-dom's buildFragment function for creating html from string, instead of declaratively and verbosely calling createElement etc calls. Just for curiosity: Should We avoid using |
ci:test:relevant |
ci:test:sf |
Jenkins Build:test-portal-acceptance-pullrequest(master)#6953 |
Reviewed. Test failures are unrelated. ✔️ Updating our ci:test:relevant filter in diegonvs#34. I don't have push rights to @diegonvs/liferay-portal. |
Hey @john-co, I invited you |
ci:test:relevant |
Jenkins Build:test-portal-acceptance-pullrequest(master)#7885 |
Hey @brunobasto, I don't need to update this for now. See: #78 (comment), #78 (comment) |
Oh thanks. Feel free to forward it then :) |
ci:forward |
CI is automatically triggering the following test suites:
The pull request will automatically be forwarded to the user
|
Skipping previously passed test suites: |
All required test suite(s) passed. |
Pull request has been successfully forwarded to brianchandotcom#91652 |
Test Case:
/group
adding for examplept
e.g(http://localhost:8080/pt/group/guest/~/control_panel/manage?p_p_id=com_liferay_blogs_web_portlet_BlogsAdminPortlet&p_p_lifecycle=0&p_p_state=maximized&p_p_mode=view&p_p_auth=UJfDKe6X
)Expected results:
No JS errors on console and the toast message (Your request was finished) will be shown adequately.
What I did
I noticed other toast containers created by JSP for example can be conflicting with React renderization of openToast. So, I decided to replace the DEFAULT_CONTAINER_ID to a unique ID used on the openToast, for not conflicting with others.
Questions
However the result was:
We aren't able to stack toast Alerts with this current implementation.
One possible thing to fix this issue is creating another command like openAlert for isolate the logic for containerId oriented alerts and left the openToast behaviour like the past API(Where We could just stack toasts and We aren't using it for every alert We got).
What do you think about it folks?
/cc @wincent @jbalsas @matuzalemsteles @markocikos @brunobasto