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
@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
@oyvindberg I must admit I haven't really explored the differences yet, and I simply started out with
It was mostly a question, to see if I should stick with
Thank you for the response by the way, I'll try to add
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.
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
stEnableScalaJsDefined will give you newable traits, so that's an option yes
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! :)
I would certainly appreciate the option to turn on apply-methods, but maybe it would be doing me a disservice 😛
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
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 :)
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.
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!
@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
@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
@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:
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
@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 ?
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 ?
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
@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
any ideas?
thanks