by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 10 21:27

    oyvindberg on react-tree-shaking

    (compare)

  • Aug 10 21:27

    oyvindberg on master

    Implement stReactEnableTreeShak… Merge pull request #191 from Sc… (compare)

  • Aug 10 21:16

    oyvindberg on react-tree-shaking

    Implement stReactEnableTreeShak… (compare)

  • Aug 09 21:47

    oyvindberg on react-tree-shaking

    Implement stReactEnableTreeShak… (compare)

  • Aug 09 20:59

    oyvindberg on react-tree-shaking

    Implement stReactEnableTreeShak… (compare)

  • Aug 09 20:59

    oyvindberg on master

    fix overflow error in SplitMeth… (compare)

  • Aug 09 20:47

    oyvindberg on react-tree-shaking

    fix overflow error in SplitMeth… Implement stReactEnableTreeShak… (compare)

  • Aug 04 22:13

    oyvindberg on v1.0.0-beta23

    (compare)

  • Aug 04 21:27

    oyvindberg on master

    Tweak bootstrap so the check fo… (compare)

  • Aug 04 18:25

    oyvindberg on react-fixes

    (compare)

  • Aug 04 18:25

    oyvindberg on master

    Tweak component selection heuri… Fix import for nested component… More properly handle MemoExotic… and 1 more (compare)

  • Aug 04 18:22

    oyvindberg on react-fixes

    Tweak component selection heuri… Fix import for nested component… More properly handle MemoExotic… (compare)

  • Aug 04 18:22

    oyvindberg on master

    Tweak logging Tweak CastConversion to ignore … (compare)

  • Aug 03 23:08

    oyvindberg on react-fixes

    Tweak logging Tweak component selection heuri… Nullary apply methods for react… and 2 more (compare)

  • Aug 02 20:48

    oyvindberg on gh-pages

    Deploy website Deploy website … (compare)

  • Aug 02 20:25

    oyvindberg on v1.0.0-beta22

    (compare)

  • Aug 02 20:06

    oyvindberg on use-module-in-package-json

    (compare)

  • Aug 02 20:06

    oyvindberg on master

    CI: Give priority to libraries … Fix #185 by heeding `module` in… intellij wants to update run fi… and 2 more (compare)

  • Aug 02 20:02

    oyvindberg on use-module-in-package-json

    CI: Give priority to libraries … Fix #185 by heeding `module` in… intellij wants to update run fi… and 1 more (compare)

  • Aug 02 19:26

    oyvindberg on react-nested-components

    (compare)

TATSUNO Yasuhiro
@exoego
It seems that JS's Promise are converted to typings.std.Promise by default.
Is it configurable to use scala.scalajs.js.Promise instead of typings.std.Promise ?
I browsed the docs, but could not find such config.
I prefer scala.scalajs.js.Promise for inter-operability with Scala classes (e.g. toFuture method).
elkhadirzyad
@elkhadirzyad
@oyvindberg , is there a stable version of @material-ui/lab i could use with mui
Roberto Leibman
@rleibman
@elkhadirzyad My guess is no, since lab is components that are temporarily there to be considered to move to core, and core is already at 4.x, and ScalablyTyped doesn't support 4.x for good reasons, my instinct tells me that lab won't work.
You could go to the last 3.x version (https://www.npmjs.com/package/@material-ui/lab/v/3.0.0-alpha.30) but my guess is that it will not have the components you want it for anyway.
I prefer semanticUI over MUI, you may find that it has components you can use.
elkhadirzyad
@elkhadirzyad
@rleibman thanks 👍
Øyvind Raddum Berg
@oyvindberg
@exoego it's meant to be replaced with js.Promise as long as https://scalablytyped.org/docs/conversion-options#stusescalajsdom is set to true (except for a few rare cases, like when something inherits from it). If that's not the case then it's probably a bug
@elkhadirzyad there's no particular reason why @material-ui/lab wouldnt work, why don't you try and report back? it could make a good addition to the material-ui demo
Andreas Gabor
@an-tex
gt
Andreas Gabor
@an-tex
oh sorry guys, children in the homeoffice... ;)
Roberto Leibman
@rleibman
@oyvindberg material-ui/lab is where they put temporary components before they make it to core, since 4.x isn't supported, I assumed lab wasn't either.
Øyvind Raddum Berg
@oyvindberg
Just pick the one which is for mui version three and most probably it's fine
trepidacious
@trepidacious
@oyvindberg Just got a chance to try out beta22, looks like it fixes AutoComplete and nested components are nicer now (Layout.Content etc.) :) The downside is that I'm still missing Menu props in antd 4.5.1, and I've also lost icons like DownOutlined as well... I'll try with 4.3.1
trepidacious
@trepidacious
Also I seem to be getting a react error that my components are undefined - I think for Layout.Header and Layout.Content
elkhadirzyad
@elkhadirzyad
@oyvindberg is there any news concerning mui 4 ?
trepidacious
@trepidacious
Ah yup 4.3.1 has the same problem, reverting to beta 20 fixes things. I’ll see if I can replicate it with simpler code tomorrow hopefully :)
Øyvind Raddum Berg
@oyvindberg
@trepidacious I'll cut a new release with ScalablyTyped/Converter#190 which fixes Layout.Header and so on. For the antd icons it was suddently upgraded by two major versions, this is how I fixed the slinky demo ScalablyTyped/SlinkyDemos@bcbce9e
@elkhadirzyad I'm trying to wrap up a first stable release now, mui4 will be after that. that work will be tracked in ScalablyTyped/Converter#125
Øyvind Raddum Berg
@oyvindberg
v1.0.0-beta23 is now out with fixes for hopefully all react flavour problems discussed the last few days
trepidacious
@trepidacious
@oyvindberg Ah great, thanks for the icon tip, I checked the docs and it didn't look like it was any different from typescript so I assumed it would be the same from scala, I should have thought to check the slinky demos. Any idea on the Menu props?
Øyvind Raddum Berg
@oyvindberg
@trepidacious I hate to say it, but it works on my machine :P
trepidacious
@trepidacious
Ah well that's a start, I'll give it another go :)
If I know it should work, I've got something to shoot for ;)
Øyvind Raddum Berg
@oyvindberg
you can check if there is a comment on top of typings.antd.menuMod.MenuProps
trepidacious
@trepidacious
Cool, I'll check that tomorrow afternoon, getting on for midnight so I'd better stop for the night!
Øyvind Raddum Berg
@oyvindberg
very good idea
TATSUNO Yasuhiro
@exoego

@oyvindberg

it's meant to be replaced with js.Promise as long as https://scalablytyped.org/docs/conversion-options#stusescalajsdom is set to true

Thanks, but I would like to use Scala.js & ScalablyTyped for Node.js project without dom, so stUseScalaJsDom with scala-js-dom depdency is overmuch.
js.Promise is a part of scalajs-library, not scala-js-dom, so I think having a configuration/flavour on ScalablyTyped is preferrable for Node.js projects.
Does it make sense ? If fine, I will try to open a PR for such config/flavour.

Øyvind Raddum Berg
@oyvindberg
Aha! That makes sense @exoego . Let's not make it configurable, it should be the default (all the types from scalajs-library really)
Andreas Gabor
@an-tex
"Enforced existence of typescript definitions", nice! happened to me a few times already ;)
elkhadirzyad
@elkhadirzyad
@oyvindberg , i have a question about chandu0101 if it is possible to respond, in ReactPopOver, val popoverHeight = $.getDOMNode.map(_.domAsHtml.offsetHeight).runNow(), domAsHtml is not recognizable, is there a solution ?
Øyvind Raddum Berg
@oyvindberg
@elkhadirzyad you're pinging me every single day with questions without seemingly putting any effort into it yourself. Stop this behaviour and start contributing instead.
elkhadirzyad
@elkhadirzyad
@oyvindberg, sorry for annoying u, a question about scalablyTyped, is this working for scalaversion 2.12 & scalajs 0.6 ?
Jocelyn Boullier
@Kazy
elkhadirzyad
@elkhadirzyad
@Kazy thanks ;)
Mathieu Prevel
@mprevel

Hi everybody !

I am using ScalablyTyped in a Slinky/ Webpack/ Electron application. I started from the g8 template.
npmDependencies in Compile ++= Npm.commonNpmDependencies ++ Seq("electron" -> "9.1.2"),
When the app is starting a BrowserWindow is opened (from the index.js file).
But I am unable to open another browser window from the scala.js context.
I'm importing with import typings.electron.global.Electron.BrowserWindow.
But the code seems to stop when it reaches new BrowserWindow() or BrowserWindow.getAllWindows().length with no error.
The UI is still responding but all the events seems to stop when reaching one of these lines.
Any idea about what could lead to this issue ?

Øyvind Raddum Berg
@oyvindberg
You may want to grab BrowserWindow through typings.electron.mod instead @mprevel
not that I have tried this myself, but it means you go through the module system instead of the global namespace
Mathieu Prevel
@mprevel
@oyvindberg It compiles but I'm struggling with webpack, so I don't know if it works :) My understanding is that the slinky template does not really build an electron app, but a web app rendered in electron. It seems there are other targets (default is 'web') like 'electron-main' and 'electron-renderer', but when setting this kind of target it crashes during startup.
If I keep the default 'web' with the typings.electron.mod it crashes during fullOptJS::webpack with ModuleNotFoundError: Module not found: Error: Can't resolve 'fs' in 'my-app/target/scala-2.13/scalajs-bundler/main/node_modules/electron'. With the electron-main target I get a Uncaught ReferenceError: require is not defined.
Øyvind Raddum Berg
@oyvindberg
Fwiw you can check out the scalablytyped demos repo, there is a an electron demo there which sets up the back end process and has a completely static frontend. It's fairly likely you'll need a frontend and a backend build in separate sbt projects. If I remember correctly you cannot use node apis directly in the browser view
mushtaq
@mushtaq
@oyvindberg I have used scalblytyped cli to generate and publish jars for some npm packages. This internally uses scalajs-dom v1.0.0 for dom types.
Our app which depends on these jars, also has an explicit dependency on scalajs-dom.
So far, the versions are matching. Now, I want to upgrade my explicit dependency to 1.1.0 which just got published.
But doing so may not be safe because cli generated jars still depend on older (and potentially incompatible) version.
This makes be think that there should cli option to specify scalajs-dom version. WDYT?
Øyvind Raddum Berg
@oyvindberg
@mushtaq scalajs-dom like all the scala.js projects has very strict backwards compatibility so I would be pretty surprised if this is an issue. Besides, the generated code really only relies on the types themselves, so even changes in methods would be fine.
trepidacious
@trepidacious
@oyvindberg Just getting back to that Autocomplete/Menu stuff, I've added some demos of those to SlinkyDemos and they do work perfectly, so it's just something weird with my project... I've added a pull request with the extra components in case it's useful. I'll have a look through the build and settings and see what's different in my project.
It's really handy to have SlinkyDemos as an example of how this stuff should be set up, since there are a few moving parts to get things to work correctly. I wonder whether it would be possible to factor some of them out in a reusable way, like the current converter plugin, but for the other bits and pieces needed to get everything working in a browser project
It's not really a ScalablyTyped thing I guess, that's just where I've run into it :)
Øyvind Raddum Berg
@oyvindberg
Thanks for the PR @trepidacious
Definitely agree, it would be awesome with some better surface for all the complexity around a scala.js app with scalajs-bundler, webpack and whatnot
And yeah, I've meant the demo projects as a help to get started, especially for the projects with... interesting build pipelines such as angular, react-native, electron
Øyvind Raddum Berg
@oyvindberg
@trepidacious it would be interesting to have a look at how they're solving this surface complexity problem for kotlin.js, I was reminded since I just read https://blog.jetbrains.com/kotlin/2020/07/kotlin-1-4-rc-released/ recently
trepidacious
@trepidacious
@oyvindberg You're very welcome :) The renderFooter bit was just to add a bit of space at the bottom (it doesn't use antd, just a div) so the end of the page doesn't look weird
mushtaq
@mushtaq

@mushtaq scalajs-dom like all the scala.js projects has very strict backwards compatibility so I would be pretty surprised if this is an issue. Besides, the generated code really only relies on the types themselves, so even changes in methods would be fine.

That is good to know. Thanks.

Øyvind Raddum Berg
@oyvindberg
ScalablyTyped/Converter#191 might do very nice things to bundle sizes