[Feature Request] Custom chat support and better treeshaking

[mateuszmichi]

What problem would this feature solve?

Hi!
I'm looking for a solution to delay loading a chat on our website. We are using freshchat and I'm aware that this one is not supported yet. I looked into contribution guide and found out that I should create a PR in such situation.
I would like to be able to skip this part during development, as it forces developers to wait for 3rd party to continue with development.
My proposal will also enable better treeshaking and code splitting. For now the problem isn't big, but with lets say 100 chats the library would grow in bundle size.

Describe the solution you’d like to see

I would like to propose a major change to the library and the way new chat can be utilized.

The templates should not be used in provider by their name, but provided as separete properties.

The strict binding (which should be considered as antipattern) is in every usage of:
const chatProvider = Providers[provider];

We could provide { domain, load, open } straight in Provider:

import { LiveChatLoaderProvider } from 'react-live-chat-loader';
import { myCustomChatConfig } from './chat';

export default class App extends React.Component {
  /* ... */

  render() {
    return (
      <LiveChatLoaderProvider {...myCustomChatConfig} >
        /* ... */
      </LiveChatLoaderProvider>
    )
  }
}

Are you willing to work on implementing this solution?

Yes

Describe alternatives you’ve considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project’s Code of Conduct

[benschwarz]

Hey @mateuszmichi, thanks for writing 👋

I'm not 100% sure I understand the proposal at the moment. We might need a little extra information to evaluate this idea. Could you describe the problem you're wanting to solve?

At the moment providers are usually submitted by people who need support for their chat tool of choice. Each provider has it's own manual testing, maintenance, and upgrades required (due to upstream changes), so the effort to maintain multiple implementations is not zero — because of this, I can't see this library quickly growing to anywhere near 100 chat implementations.

Coming back to your mention of treeshaking — Have you noticed a potential optimisation?

Having said all that, if you're interested in working on a Freshchat implementation (#109), I'd be more than happy to help get it reviewed and released. I'd prefer to add Freshchat support than a custom solution that changes the existing library so dramatically for one use case.

[benschwarz]

Closing for now. LMK if you want to circle back to this conversation @mateuszmichi