You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have a rich Application Bar component which is shared across several React and non-React applications. The component is bundled into two flavors -
As an importable React component.
Wrapped in a script shell which is included in web applications through a traditional script tag. This allows the component to be hosted in non-react web applications as well. The wrapped version internally calls ReactDOM.render to mount the component on a host provided dom element. The webpack bundling configuration of this script has React and ReactDOM declared as external dependencies to ensure we don't enrage React if it's already loaded in the host website for any reason.
Currently this component uses React-Bootstrap components. Recently we started migrating to material design and having past success and familiarity with material-ui, it was our first choice. However in this case, we soon got blocked by the react-tap-event-plugin dependency. This plugin currently doesn't seem to have a way to work with externalized React dependencies and this causes the plugin to not register currently with ReactDOM in the global context (window.ReactDOM). This is a complete blocker for us. And looks like despite the browsers now inherently supporting the features polyfilled by this plugin, we still get loads of errors with material-ui as it internally adds onTouchTap props on its components, causing React to throw up errors for unsupported propTypes.
Is there a possibility of a workaround here? We are willing to pull a PR if you folks can guide us through the possible solution. Alternatively, do you already have this on the road-map and would it be possible to share estimates (very rough will do)?
Thanks.
The text was updated successfully, but these errors were encountered:
it internally adds onTouchTap props on its components, causing React to throw up errors for unsupported propTypes
If material-ui is passing internal Material-UI non-dom props to dom element, please open an issue with specific details (and by all means submit a PR).
Alternatively, do you already have this on the road-map
react-tap-event-plugin is removed in the next branch (npm i material-ui@next)
Please see my original issue posted here - zilverline/react-tap-event-plugin#98.
We currently have a rich Application Bar component which is shared across several React and non-React applications. The component is bundled into two flavors -
script
tag. This allows the component to be hosted in non-react web applications as well. The wrapped version internally calls ReactDOM.render to mount the component on a host provided dom element. The webpack bundling configuration of this script has React and ReactDOM declared as external dependencies to ensure we don't enrage React if it's already loaded in the host website for any reason.Currently this component uses React-Bootstrap components. Recently we started migrating to material design and having past success and familiarity with material-ui, it was our first choice. However in this case, we soon got blocked by the react-tap-event-plugin dependency. This plugin currently doesn't seem to have a way to work with externalized React dependencies and this causes the plugin to not register currently with ReactDOM in the global context (window.ReactDOM). This is a complete blocker for us. And looks like despite the browsers now inherently supporting the features polyfilled by this plugin, we still get loads of errors with material-ui as it internally adds
onTouchTap
props on its components, causing React to throw up errors for unsupported propTypes.Is there a possibility of a workaround here? We are willing to pull a PR if you folks can guide us through the possible solution. Alternatively, do you already have this on the road-map and would it be possible to share estimates (very rough will do)?
Thanks.
The text was updated successfully, but these errors were encountered: