by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 07 20:02

    oyvindberg on sbt14

    scalafmt (compare)

  • Sep 07 19:56

    oyvindberg on sbt14

    Bump sbt to 1.4.0-RC1 (Fix #168) (compare)

  • Sep 06 19:27

    oyvindberg on disable-scalajsdefined-traits-with-setters

    (compare)

  • Sep 06 19:27

    oyvindberg on master

    traits with setters cannot be `… Merge pull request #197 from Sc… (compare)

  • Sep 05 20:14

    oyvindberg on disable-scalajsdefined-traits-with-setters

    traits with setters cannot be `… (compare)

  • Sep 03 21:16

    oyvindberg on stMove

    wip stMove (compare)

  • Sep 03 20:59

    oyvindberg on disable-scalajsdefined-traits-with-setters

    traits with setters cannot be `… (compare)

  • Aug 31 00:16

    oyvindberg on gh-pages

    Deploy website Deploy website … (compare)

  • Aug 30 23:55

    oyvindberg on v1.0.0-beta25

    (compare)

  • Aug 30 23:46

    oyvindberg on tagmod-and-spreads

    (compare)

  • Aug 30 23:46

    oyvindberg on master

    Extend scalajs-react integratio… Add `unsafeSpread` to scalajs-r… Add explicit `build` method to … and 1 more (compare)

  • Aug 30 23:00

    oyvindberg on tagmod-and-spreads

    Add `unsafeSpread` to scalajs-r… Add explicit `build` method to … (compare)

  • Aug 30 22:37

    oyvindberg on tagmod-and-spreads

    Add explicit `build` method to … (compare)

  • Aug 30 22:30

    oyvindberg on tagmod-and-spreads

    Extend scalajs-react integratio… Add `unsafeSpread` to scalajs-r… Add explicit `build` method to … (compare)

  • Aug 30 22:07

    oyvindberg on tagmod-and-spreads

    Extend scalajs-react integratio… Add `unsafeSpread` to scalajs-r… (compare)

  • Aug 26 19:44

    oyvindberg on master

    Remove parallel runner, disable… (compare)

  • Aug 26 19:23

    oyvindberg on master

    chore(Dependencies) : update li… Merge pull request #193 from mv… (compare)

  • Aug 24 04:22

    oyvindberg on classes-can-not-extend-js-promise

    (compare)

  • Aug 24 04:22

    oyvindberg on master

    Follow-up from #192: Don't let … (compare)

  • Aug 24 04:11

    oyvindberg on upgrade-bloop

    (compare)

Øyvind Raddum Berg
@oyvindberg
but the question for me is rather why you want to you scala-js-nodejs instead of the generated typings.node. If you prefer it for some reasons I'd be happy to hear them all :)
and re: node 14.0.2 it now apparently needs BigInt, where it didnt before. This can be added to typings.std through specifying for instance esnext instStdLib. Perhaps bumping typescript itself to 4 would also fix it, I haven't had the time to investigate yet
Øyvind Raddum Berg
@oyvindberg
@molikto The choice is yours. typings.std is generated based on the (very complete, very up to date) typescript definitions of the javascript std library and the dom, whereas scalajs-dom is manually written. For me typings.std is better, but scalajs-dom is better if you need interop with other scalajs libraries. See also https://scalablytyped.org/docs/conversion-options#stusescalajsdom
Alexander Samsig
@Asamsig
@oyvindberg I must admit I haven't really explored the differences yet, and I simply started out with scala-js-node, since I was already depending on another project from the same org. I'm not expecting to use very many Node-specific things.
It was mostly a question, to see if I should stick with scala-js-node, and later fix a flavour for ST if I saw the need, but maybe I should just stick to typings.std. My assumption is that scala-js-node is a bit more friendly, since it has been improved manually, as far as I can tell.
Thank you for the response by the way, I'll try to add esnext to stStdLib and see if it fixes my issue.
Øyvind Raddum Berg
@oyvindberg
That may very well be true that it's more friendly @Asamsig , I haven't had the time to look closely. I would be quite surprised if it wasn't based on code generation with manual touch up though, and most manual touchup could also be done automatically :)
I've spent time making react integration awesome lately and haven't focused much on node stuff. It could be that a node flavour could help a lot, I don't really know
ScalablyTyped/Demos@0dd24ff I upgraded the demos to use newest node definitions, it needs esStdLib := List("esnext") to get BigInt
Alexander Samsig
@Asamsig
@oyvindberg Yep theesnext-flag, solved the compile error, thanks!
przemyslaw wierzbicki
@pshemass
Hi, I'm trying to understand why not all component with Flavor.Slinky are generated for @material-ui/core -> 4.10.11. It looks like AppBar, TextField and many others are there but Button and IconButton are missing. Is it expected or I missing something?
Øyvind Raddum Berg
@oyvindberg
@pshemass version 3.9.3 works, supporting 4+ is tracked in ScalablyTyped/Converter#125
Alexander Samsig
@Asamsig
I see there has been some changes to how the facades work, if I prefer constructors, is it stEnableScalaJsDefined, I'm looking for ?
przemyslaw wierzbicki
@pshemass
thanks @oyvindberg. do you need any help with that?
Øyvind Raddum Berg
@oyvindberg
@Asamsig I suppose by constructors you mean apply methods on the companion objects like there was before? I took them out because I think the new builder pattern is so much better. If you haven't given that a proper trial I'd definitely recommend it
stEnableScalaJsDefined will give you newable traits, so that's an option yes
Alexander Samsig
@Asamsig
That is what I gathered, when I went looking in the changelog.
Øyvind Raddum Berg
@oyvindberg
so if you hate the new approach it's pretty easy to re-add support for how it was, it's really just a boolean
but like I said, I really think this approach is much better
@pshemass well yes I do, but when I haven't done it yet it's because it's really hard! :)
Alexander Samsig
@Asamsig
I'm toying with translating some typescript into scala.js, so it is mostly that it requires me to change the code more, compared to to typescript. It also feels like less idiomatic Scala, but I certainly understand the issues, with type inference etc
I would certainly appreciate the option to turn on apply-methods, but maybe it would be doing me a disservice 😛
Øyvind Raddum Berg
@oyvindberg
Yeah I get it, but it's not hopelessly unidiomatic either. Immutable builders are fairly common, and these mutable builders can be used as such with some .duplicate in the right places. In exchange for picking mutable builders we get pretty much optimal javascript, and freedom to compose and mutate javascript objects after construction
Øyvind Raddum Berg
@oyvindberg
anyhow the diff for this file (plus threading through a boolean) is enough to re-enable the old apply methods, just in case you're in the mood for a PR :)
Alexander Samsig
@Asamsig
Thank you for the link, I'll do some experimenting tomorrow, and see if ScalaJSDefined is enough. Otherwise I just might send a PR. 👍
Øyvind Raddum Berg
@oyvindberg
just note that it won't be accepted unless you swear you've given the builder approach an honest try :D
przemyslaw wierzbicki
@pshemass
@oyvindberg what is the best way to run and debug compilation of only one library locally?
Alexander Samsig
@Asamsig
My main motivation is really getting the code to work in Scala.js with the least amount of changes. So ideally I wouldn't need to change object construction into builders, since that would be quite jarring in a showcase. At this point I'm willing to live with quirks, but this is probably not a common case, and would be a bad default for sure.
mn98
@mn98
Hi all, I’ve been enjoying this library in conjunction with Slinky and I’ve had some success pulling in Chart JS. However I’ve been unable to figure out how to turn x-axis into time in the same way that would be done in JS. Would anyone happen to have an example or know how to achieve this within ScalablyTyped? Thanks!
Øyvind Raddum Berg
@oyvindberg
@pshemass If you're really gonna hack on mui4 at least read this article to know what you're getting yourself into: https://blog.andrewbran.ch/polymorphic-react-components/ . They made a habit out of crashing the typescript compiler there for quite a few releases
@pshemass other than that I recommend to use the cli tool. Install the libraries you want to debug with yarn into a folder, and run the cli tool direcly from intellij and point it to that directory. For more focused debugging I definitely recommend minimizing things into tests. ImporterTest is what I've used the most, but for mapped types specifically there is also another harness which can be useful
Øyvind Raddum Berg
@oyvindberg
@Asamsig yeah if you already have some code it makes sense to not immediately migrate it. If you decide to make that PR you can pretty much revert the commit I linked. I would appreciate it if you could "flip" the boolean and call it something like "generateLongApplyMethods" or I don't know what, something like that. At least indicate it's not the default
Alexander Samsig
@Asamsig
@oyvindberg For sure. I'll make sure to add some information to the documentation as well, that it isn't recommended, because of various issues as you mentioned.
If I end up adding it back :)
Øyvind Raddum Berg
@oyvindberg
@mn98 I have no idea, this demo is all I ever knew about chart.js . Find some typescript/javascript example code with what you're trying to achieve and make a PR against that demo repo with a precise description of where it stops, then I'll have a look :)
@Asamsig :thumbsup:
Øyvind Raddum Berg
@oyvindberg
also @mn98 I wrote a slinky demo for nivo and found that quite a bit more awesome, you may want to look at something like that instead
mn98
@mn98
@oyvindberg nivo does look pretty cool! I shall give that a go.
Alexander Samsig
@Asamsig
@oyvindberg I was wondering if the apply-method problem, is mostly React component based, or what is your experience here?
Currently I'm exploring some Node APIs, and I don't think the apply-methods, would be a real problem.
I'll write my PoC with the new builder-API, and then I'll revisit and experiment with the apply-methods, to see if it could work well for the APIs I'm using. Because I'm guessing it is actually very API dependant ?
Øyvind Raddum Berg
@oyvindberg
It's extra painful for react components because so many of them have 255+ props because of the DOM. But IMO the benefits are real for all types regardless of the number of props
Robert Walker
@olofwalker
When is Beta26 scheduled?
Øyvind Raddum Berg
@oyvindberg
There are PRs for sbt 1.4.x support and for a change relating to BigInt, other than that I'm hopeful I can slap RC1 on a release with few changes quite soon
Øyvind Raddum Berg
@oyvindberg
For me the state of react integration is very good now, with the obvious exception of mui4 and so on. I suppose there is much much more we could do with other pieces of the Javascript ecosystem (like node), but that can come later.
Robert Walker
@olofwalker
I agree, could keep adding things for a long time
mvillafuertem
@mvillafuertem

Hi there, any examples using react-redux ?. I have tried using it in this project but I don't know what I am doing wrong

https://github.com/mvillafuertem/scalajs-react-world/tree/master/modules/journal/src/main/scala/io/github/mvillafuertem

Øyvind Raddum Berg
@oyvindberg
@mvillafuertem short answer is use diode instead, it'll be much more pleasant. If you want to see how it worked when there was a redux demo check out here https://github.com/ScalablyTyped/SlinkyDemos/tree/25724604bdb106333cc64a2385d65751086a2512/semantic-ui-react/src/main/scala/demo
mvillafuertem
@mvillafuertem
@oyvindberg Thanks for the link! :)
Alexis Hernandez
@AlexITC
I started getting this error while compiling slinky components: java.lang.OutOfMemoryError: Java heap space
any ideas?
Øyvind Raddum Berg
@oyvindberg
Of you're compiling from within an idea import, like in intellij, try to run it from normal sbt instead. If you're already running normal sht Google how to give it more heap space
Alexis Hernandez
@AlexITC
I was surprised by the error because I ran some slinky examples without problems, and other projects using scalablytyped, anyway, after increasing the heap memory, the problem is gone
thanks
Øyvind Raddum Berg
@oyvindberg
yeah, compiling all of this stuff sometimes takes quite a bit of memory unfortunately.