search

gadicc / meteor-blaze-react-component

<Blaze template="itemsList" items={items} />
https://atmospherejs.com/gadicc/blaze-react-component
MIT License
61 stars 12 forks source link

1.1.2 introduced conflict with meteor-blaze-components #9

Closed pward123 closed 8 years ago

pward123 commented 8 years ago

When I upgraded from 1.1.1, I started having problems because the BlazeComponent being globally exported conflicts with https://github.com/peerlibrary/meteor-blaze-components.

I could be wrong, but it seems like the global exports from this package are extraneous. Would you be open to the idea of removing them?

gadicc commented 8 years ago

Hey. Good question.

I'd love to rip out the global exports. Unfortunately, there's a fairly sizeable segment of Meteor users who are hating on the new module system and still use globals "because it's easier and works perfectly".

Having said that, probably most people using React in Meteor are not in this category, and actually, I didn't even mention the BlazeComponent global in the README. Still, exports are required for weak deps on Atmosphere packages. So, I think our best bet is to simply rename it to BlazeReactComponent.

I'm curious though about the problems you're experiencing. Where is the BlazeComponent global relied upon in a way where the correct one can't be explicitly imported?

pward123 commented 8 years ago

It looks like I was able to work around the problem by reordering the package references in /.meteor/packages.

This is a legacy application. We have both blaze templates and react components inside the /client folder (no lazy loading yet). So, we have to put both packages in /.meteor/packages.

If your package were npm installable (in addition to being an atmosphere package), that would eliminate the problem as well.