move to new organization scalajs-react-interface

[chandu0101]

Hi, Till now sri is under single owner,its definitely not scalable option in long run , lets distribute owner ship(maintenance & publishing). from now onwards all future work will be done under https://github.com/scalajs-react-interface. as we're moving to more stable place lets make architecture changes and breaking changes now!.

Separate Project for each module :

Core : react core types and component/element construction helpers/factories.

Universal : Components and API's that will work across multiple platform (web,ios,android,macos,windows)

Relay : react-relay

Web: ReactDOM and html tags,svg tags etc

Mobile : react-native

Other Platforms..

by having separate project we can iterate rapidly, for example if @dispalt want some change in relay and @nafg want some change in web, they can make their changes in isolation and publish it without worrying about other projects ..

[dispalt]

I like it alot. I've been converting my third party components over to that method independently, with 0.6.14 and 2.12 it's much nicer now, so I am huge +1 on that. For dom tags I actually copied @japgolly's approach and did https://github.com/dispalt/sri-vdom which I personally like; however, there are drawbacks as it doesn't give a ton of guarantees but suits my approach well.

Lack of macros will also speed up compile-time.

For 3rd party components, the 2nd con, you can use js.defined(f => foo) and it will handle the implicits, which again is nice.

[chandu0101]

with 0.6.14 and 2.12 it's much nicer now

can you elaborate what 2.12 offers more for @ScalaJSDefined trait ..

For dom tags I actually copied @japgolly's approach and did https://github.com/dispalt/sri-vdom which I personally like; however, there are drawbacks as it doesn't give a ton of guarantees but suits my approach well.

👍 , actually my plan is to web module just contains ReactDOM facade and helpers and provide vdom in separate project https://github.com/chandu0101/sri-web-vdom ,so that users can come with different flavors of vdom which fits their taste buds/needs(server-rendering).Your use case is one classic example so lets do that.

For 3rd party components, the 2nd con, you can use js.defined(f => foo) and it will handle the implicits, which again is nice.

cool , thanks for the tip I'll update cons section :)

[dispalt]

Yeah neat, http://www.scala-js.org/news/2016/12/21/announcing-scalajs-0.6.14/ refers to SAM methods and leaving off type ascriptions. I had to ditch sri-web and copy over that stuff so the Dom stuff would be a welcome change.

On Sat, Jan 7, 2017, 8:36 PM Chandra Sekhar Kode notifications@github.com wrote:

with 0.6.14 and 2.12 it's much nicer now

can you elaborate what 2.12 offers more for @ScalaJSDefined trait ..

For dom tags I actually copied @japgolly https://github.com/japgolly's approach and did https://github.com/dispalt/sri-vdom which I personally like; however, there are drawbacks as it doesn't give a ton of guarantees but suits my approach well.

👍 , actually my plan is to web module just contains ReactDOM facade and helpers and provide vdom in separate project https://github.com/chandu0101/sri-web-vdom ,so that user can come with different flavors vdom which fits their taste buds.Your use case one classic example so lets do that.

For 3rd party components, the 2nd con, you can use js.defined(f => foo) and it will handle the implicits, which again is nice.

cool , thanks for the tip I'll update cons section :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chandu0101/sri/issues/55#issuecomment-271129343, or mute the thread https://github.com/notifications/unsubscribe-auth/AACz1VKlXf8Q_tRuMMdE16V79g1PIwa0ks5rQGfmgaJpZM4LdlcC .

-- -Dan

[chandu0101]

0.6.14 refers to SAM methods and leaving off type ascriptions.

we can hack around that by defining as vars! which will work fine 2.11/2.10.

[dispalt]

Yeah I prefer the immutable variant, but to each their own. =)

On Sat, Jan 7, 2017, 8:55 PM Chandra Sekhar Kode notifications@github.com wrote:

0.6.14 refers to SAM methods and leaving off type ascriptions.

we can hack around that by defining as vars! which will work fine 2.11/2.10.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chandu0101/sri/issues/55#issuecomment-271129962, or mute the thread https://github.com/notifications/unsubscribe-auth/AACz1YY_tKcU6EatcwiFljP9tvUhhyINks5rQGwlgaJpZM4LdlcC .

-- -Dan

[nafg]

I don't see a good reason to combine renaming the artifacts with breaking changes. Even if you want to do them simultaneously the changes should have their own ticket. It will affect a lot of users and they might not find the discussion.

I object to at least some of them but it seems difficult to discuss on a ticket about something else.

[chandu0101]

I object to at least some of them but it seems difficult to discuss on a ticket about something else.

fair enough , i'll create tickets for dom tags & third party & webstyles ,lets keep this for organization stuff.

[Andrei-Pozolotin]

guys: what is your time frame for transition to https://github.com/scalajs-react-universe?

[chandu0101]

once scala-js 0.6.15 released , I'll push first beta in couple of days.

Sjrd : Wait for 0.6.15
Andrea Peruffo @andreaTP Feb 26 19:26
sjrd ok, thanks!  any eta?
Sébastien Doeraene sjrd Feb 26 20:20
2-3 weeks, I would say

[Andrei-Pozolotin]

great. probably would make sense to publish an S.R.U. "road map" on the org site?

[chandu0101]

i created a ticket for this : https://github.com/scalajs-react-universe/support/issues/1 , lets use this until we release first beta,after that we'll discuss with community and create a detailed road map :)