Hey all, happy almost New Year! We at AirDev wanted to do a little experiment and release a group messenger built on Bubble, along with the public editor view of the messenger
To see/test the messenger, go to http://messenger.airdev.co
To see the editor view, go to https://bubble.io/page?name=index&id=messaging_public&tab=tabs-1 (this is a different app than the one above, in case it ends up breaking and to protect people’s emails)
Awesome work and thank you for sharing it with the community! I am implementing messaging as well and I find it very helpful seeing how other users accomplish the same task.
Anyone else having an issue opening the editor view for this? I keep getting a popup that says that the data can’t be loaded.
Curious, as I’d really love to take a look at this!
Fantastic!
Unfortunately, I can’t see the editor view either. Its a “we’re loading your app” message that times out.
maybe @emmanuel or @georgeciobanu can take a look as to why that’s happening? The messaging_public app is set as public on my end
@emmanuel I’m having this same issue on a public app as well.
We’ll look into this ASAP.
Sweet @vlad nice one 
Thanks for open sourcing this resource.
I found an issue where you must scroll to see new messages on other clients than yourself.
The optimal way would be to have the app update on new message via the “websocket subscribe” it currently uses to fetch data. Currently I`m not too familiar with the on data changed functionality under workflows, but we can do a workaround by creating a pseudo field which is hidden and linked to the messages:last. Then we monitor that field for changes and execute a scroll to bottom when a change occurs.
Additionally, when a new message is detected we want to not scroll down when a user has scrolled up to read a message higher up. But to show some sort of notification displayed after the repeatinggroup of messages and before the newmessage box. This has to be done via custom javascript hidden in a custom-html-element which is set to a condition to display when the ondatachange fires.
This can be done either with both function and execution stored in the custom-html-element, or just function-execution there and the full js function loaded via the site settings custom javascript. Jquery seems to be loaded so we could do something like this to check if the scrollposition of a div is at bottom or not.
function isScrolledToBottom(el) {
var $el = $(el);
return el.scrollHeight - $el.scrollTop() - $el.outerHeight() < 1;
}after a little thought I think we also could do something else to always keep the div scrolled to bottom if its not scrolled up. This removes the necessity for most of the previous stuff except one would need to add the notification about new messages when scrolled up.
Here is some idea, but it seems to need to be updated with interval. How could we make the scroll pinned to bottom without running a interval counter.
Thanks for pointing that out @gurun - a bug indeed!
I would prefer to avoid using code as a solution - can anyone think of a creative native bubble way to solve this? I thought about setting up an action to execute every 1 second that will scroll to the bottom of the repeating group. However, that messes with the ability of the user to scroll up and see previous messages.
I`m not a fan of using the “every second”, trigger as it is not a best practice approach. The best would be to have bubble do an action triggered when new data arises from the firebase “websocket” connection.
@georgeciobanu Do you think it would be hard to fire actions on new data this way (on new_firebase data received)?
Also, I wrote a post on some logic for storing message.scrollposition on mousehover, but the logic turned out to be hard to do with workflows so I scrapped it. What about showing a notification when there is new messages, displayed between messagebox and messagelist "There is new messages [button] Scroll down to last message [/button].
Hi,
it seems that the app is broken in dev-mode (https://bubble.io/page?name=index&id=messaging_public&tab=tabs-1)
So, I am wondering how much regarding the workflow is still OK…
Yes looks like a bunch of stuff was deleted, just restored an older version!
Is there some kind of “clone this app” option to make our own “local” copy?
Someone may have found this out already but just incase anyone is wondering about having the repeating group scroll to the bottom whenever a new message is created (no matter the user), I did this using custom states here:
When the page is loaded, the repeating group scrolls to the last entry of the repeating group (the bottom):
Then I created a custom state on the repeating group called ‘Number’ (which is the ‘Count’ of the repeating group’s messages at the time of page load):
Then in a different workflow I created a ‘Do when condition is true’ (Every time):
And set the Repeating Group’s Number state back to the new count of Messages:
And then I think it should scroll to the bottom every time 
To test you can open the preview in a chrome window and another in an incognito window, scroll to the top of the group on each, create a new message in one window, and the repeating groups in each window should scroll to the last entry at the same time.
Editor: Forumapp3 | Bubble Editor
Preview: https://forumapp3.bubbleapps.io/version-test/scrolltoentry_messaging?debug_mode=true
I have making the web application for my client company which changing the way of the customers come and feel the car in the exhibitions. I name it “giá xe toyota” and it work really well on my artwork. Thank you bubble a lot for making this platform. I think that i will use my company account to subscribe your dedicate server.
Yes! Good job and thanks for sharing!!
I’m having problems with this solution. If the repeating chat group takes too long to load, it doesn’t automatically scroll to the bottom. Have you run into this error?
I understand the theory behind this solution and it appears to work, but I don’t understand the workflow when it is executed step-by-step (below). Could somebody help me out here
When page is loaded, this is the view (probably less than 10 repeating group cells loaded).
By the end of the 1st workflow, this is the view. Note that the custom state has a value of 178 (which is the number of repeating group cells loaded on the page at that time).
It is the next workflow that I don’t understand.
According to the below evaluators, the actual number of repeating group cells in the database is 178. Whereas
s the number of repeating group cells loaded on the page is apparently empty (it should be 178 according to the custom state previously set in step 2 of my post).
In the end, this workflow is executed because 178 is of course greater than an empty value, which results in the below view.
To summarize, the scrolling to the very bottom of the repeating group is nice, but I’m unsure that the workflow used to get to this result makes sense (since, in this case, 178 or whatever number of database entries is present, will always be greater than an empty custom state). Essentially, this is just a workflow that scrolls to the bottom twice. In fact, I have a workflow that just scrolls to the bottom of a repeating group twice in my project, and this works fine and is much more simple (without the need to set custom states). Could someone clarify or correct my interpretation?
