I think we have 2 different features here, and maybe would be better if we splitted into 2 different prs

its better to revert if we had some problem, and helps our release process...

what do you think @tassoevan ?

There is no problem creating two pull request, I'll do it.
Done.

Does this maximize and minimize open and close the widget? Or, just make it full screen width and height? I'm looking for a way to open the live chat programmatically with something like RocketChat.livechat.open(), .close().

Does this maximize and minimize open and close the widget? Or, just make it full screen width and height? I'm looking for a way to open the live chat programmatically with something like RocketChat.livechat.open(), .close().

Yeah, it will do exactly what you're looking for, but I'm moving that implementation to another pull request.
Thanks.

RocketChat/feature-requests#135

I don't like the idea of piercing the showAgentInfo prop through the components... That's why Context API exists. Also, in some presentational components, just omitting the agent prop does the trick. What about implement an AgentInformationContext and wrap the ChatContainer with the AgentInformationContext.Provider?

There are other events where we need to deal with the permission, like the onTyping, so we can't just omit the agent prop.

I don't like the idea of piercing the showAgentInfo prop through the components... That's why Context API exists. Also, in some presentational components, just omitting the agent prop does the trick. What about implement an AgentInformationContext and wrap the ChatContainer with the AgentInformationContext.Provider?

There are other events where we need to deal with the permission, like the onTyping, so we can't just omit the agent prop.

In addition: What I can do is not send the agent info on backend side and then reduce the propagation of the showAgentInfo. but I'll need to use it in specific methods, like the onTyping.

Well, at least we must give a try to the AgentInformationContext idea. The Chat, for instance, just carries the prop to give it to the Screen component... This is error-prone and a waste of time.

@ggazzo, this PR is ready to review/merge, as well as the related PR on the backend side.