search

zetachang / react.rb

Opal Ruby wrapper of React.js library.
http://reactrb.org/
MIT License
547 stars 35 forks source link

GEM Separation / Issues #137

Open wied03 opened 8 years ago

wied03 commented 8 years ago

The core of this issue is agreeing on separation and then creating further issues for each of these to track/make that work happen.

Here is what I've gathered from the thread. Separate into these GEMs:

  1. react.rb: React.js wrapper w/ ruby like syntax/interface.
  2. opal-isomorphic-utils: to provide the facility for passing context into ExecJS - separate repo + gem
  3. reactrb-rails: Install and component generators, ActionView and ActionController renderers. - separate repo + gem
  4. testutils - facilitate unit testing components - may live in the core react.rb repo, but separate gem
wied03 commented 8 years ago

Assuming this is going to split into 2 or 3 GEMs, maybe each GEM could be made an issue label and the issues can be tagged appropriately. If this is going to happen, it might be handy to split these out into multiple repos (under the new reactrb org)?

ajjahn commented 8 years ago

I see the need for 3 gems:

  1. react.rb: React.js wrapper w/ ruby like syntax/interface.
  2. opal-isomorphic-utils: to provide the facility for passing context into ExecJS
  3. reactrb-rails: Install and component generators, ActionView and ActionController renderers.

I'm not sure those are the perfect names, but we can always change them later. If it is agreeable, we should go ahead and categorize the issues with some matching labels.

I think it might be premature to split them into separate repos. Primarily because as it stands right now, everything is pretty tightly coupled. I would like to see refactoring take place to begin separate concerns and make our way toward extracting the other gems. But I'm open to ways to move faster to toward that end.

wied03 commented 8 years ago

@ajjahn It seemed like from the code that #1 is rather isolated from #3 already, no?

I definitely agree with keeping #2 separate. Rails should not be required for the core GEM (I would include react-rails in that).

I currently have an internal build of react-rails that does the Opal stuff, removes the babel/JSX stuff, etc.. I've been pondering how to make that less internal.

catmando commented 8 years ago

Agree.

For clarity my understanding is that 3 uses 2, and for example you could have reactrb-sinatra that would also use 2.

And how about reactrb-testutils or some such? (or are you just focusing on the what is already in reactrb that needs to get broken out...)

wied03 commented 8 years ago

Setting a goal for a 4th (testutils) sounds fine to me. My main goal here is trying to grasp the state of the project and see where the open issues are heading.

catmando commented 8 years ago

lets keep the testutils on a separate issue then...

wied03 commented 8 years ago

I think where this stands then is if you guys do a README (that expands on what's already there) that outlines how the split would work, then apply some labels to the issues that mark them accordingly, this issue can be closed.

ajjahn commented 8 years ago

@wied03

It seemed like from the code that #1 is rather isolated from #3 already, no?

1 and 3 are closer to being separated. I worked on that a while back. Although, I can't say they are completely separate.

@catmando @wied03 To me the test utils belong in the react.rb repo. What I've worked on so far on that front is particularly targeted at unit testing react.rb components. It does not require any additional frameworks nor make any assumptions about server side setups. It is meant to wrap React.js's TestUtils. We are already using those utils to test react.rb itself.

Keep in mind, the test utilities aren't required by React.rb. If you want to use react.rb in a project or to build your own component lib/gems, you can simply require and include the test utils in your test helper. Otherwise it doesn't add any extra baggage.