https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# papercups
s
This message was deleted.
k
Hey Ken to update the client identity we have parameters in the options section https://github.com/papercups-io/chat-widget I don’t think we have a Svelte component yet so most likely you need to go with global HTML config. @alex can probably confirm this. Our React/vue components are just wrappers around our iframe https://github.com/vmarnauza/vue-papercups It would be cool to have a Svelte component though if the community would be opened to contributing.
k
Thanks for the quick response! So… if I update the 
customer
params on 
window.Papercups.config
after the widget has been initialized, will those changes be picked up?
u
Yep exactly!
k
Btw how did you find Papercups and are you using it for a personal project?
k
I think I first saw it mentioned on HN and added it to my personal Airtable base of “things I might want to remember about later”…
I am working on a bootstrapped startup … getting ready to launch an invite-only beta (and hopefully a public beta a month or so later) … thought I should include an easy way for people to get support / provide feedback.
u
Oh nice congrats on the startups! Yeah being able to chat with people is pretty important 🙂
k
Thanks again for your support. I’ll go with the global setup for now… but I’ll consider creating a Svelte wrapper down the road.
k
Great keep me posted on how the private beta and launch goes.
k
One additional question. I’m loading the global papercups 
<script>
tag from within a svelte layout component. I have two separate layouts based on whether the user is authenticated or not. If someone logs in or out, the svelte router un-mounts / re-mounts the appropriate layout…
This results in multiple 
<div id="PapercupsChatWidget">
elements.
Is it sufficient for me to destroy the above element in the 
onDestroy
(un-mount / cleanup phase) of my layout? (in order to prevent memory leaks and/or strange behavior arising from multiple papercups widgets?)
u
Hmm I might try to do it with a single element then you don’t have to deal with the state of creating and destroying. Is this mainly for a boolean flag of authenticated or not?
k
Not exactly. I’m trying to find the simplest way to integrate papercups given my app’s current design with two separate layout components. In current form, neither layout would “know” whether the other has been previously mounted (causing the global papercups script to be loaded). I can also address this by adding some global shared state and only injecting the papercups 
<script>
if it hasn’t previously been loaded.
(adding global shared state is a bit of a code smell… so I was trying to avoid it… but not a big deal)
(I’m a pragmatist 😏)
a
hey! sorry, we definitely need to improve the setup for non-react SPAs... hoping to add more useful client-side APIs (e.g. 
Papercups.identify(customer)
) but for now you might need to hack around it a bit 😕
k
No worries! I have a thought on how to encapsulate this for now… will report back on how it works out.
❤️ 1
Checking back to confirm something. An earlier response at the beginning of the thread indicated that a change to 
window.Papercups.config
after the global 
<script>
widget initialization would still be picked up – e.g., as a way to set customer details after login. From my testing so far, this doesn’t seem to be the case. Can you confirm?
a
yes sorry, that was incorrect on our end
k
OK… no worries – I get that I’m implementing this a bit outside of your off-the-shelf approaches.
I’m wondering what you would suggest for this scenario…
Say the global script first loads when the user is not authenticated (and this is reflected in 
window.Papercups.config
before the global script is added)…
now the user authenticates. The svelte layout for unauthenticated scenario will un-mount. In my 
onDestroy
cleanup, I could destroy the 
PapercupsChatWidget
element… then in my layout that’s used for authenticated context, re-inject the global script. Is removing the 
PapercupsChatWidget
element sufficient “cleanup” to avoid issues associated with loading the global script multiple times? Some other recommendation?
I’m looking at the 
vue-papercups
repo for some inspiration here – I see in 
destroyWidget.js
that it destroys both the chat widget and the previously injected 
<script>
tag, which makes sense. I will try to follow that approach (unless you have another suggestion).
a
that sounds reasonable 👍
k
Closing the loop on this – that second approach outlined above basically worked. I was able to use the chat widget in the unauthenticated / unidentified context, chat with myself as an admin, then log in, see a new conversation in the inbox for the identified user (not ideal, but serviceable)…
The problem is… removing both the global 
<script>
element and the chat widget element is not adequate cleanup – there must be some residual event listeners registered outside of the 
PapercupsChatWidget
element which I don’t have any way to un-register – so I see console errors when I send a reply from the admin UI.
Besides the annoying errors themselves, this means I would have a memory leak – every time someone logs in/out without doing a page refresh, we’ll have a growing herd of zombie event listeners 🧟 🧟‍♂️ 🧟‍♀️ 🧟‍♂️ 😱
Unless you have another suggestion, I am going to move on to try a competitor product. Papercups looks cool, but doesn’t seem to work yet for my specific scenario: • SPA svelte / sveltekit app • login / logout does not result in page load • want customer to be able to chat unidentified when not authenticated / identified when authenticated
Thanks again for your support! Let me know if you have an alternative approach I should try.
a
hmm yeah, seems like having a 
identify
method that you can just invoke whenever you want to switch between anon/identified users might solve things?
k
Yes, that would definitely be one way to address this use case. I think it would be especially nice if you have a user who starts anonymous… and then they are identified… the prior chat history / context is retained and/or merged.
a
yup exactly 👍
we're a little slammed this week, but hoping to have that fixed by next week
6 Views
Open in Slack
PreviousNext
Powered by