ScalablyTyped/community

https://scalablytyped.org/docs/plugin

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

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 should be https://scalablytyped.org/docs/plugin#requirements

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

Where communities thrive

People

Repo info

Activity