I am trying to use material-ui from Kotlin. (Am going quite well and will release it to the public if it all works OK.)
I am a bit of a newbie to Javascript (and Kotlin for that matter).
I am looking for a simple way to expose a theme to my components. I have looked at the withThemes stuff, but it is not working supper well for me.
I would like to define some type of global (maybe) theme object.
Is there an easy way to get the current theme without wrapping the component using withThemes?
Thanks for any help.
C
I got Material-UI working from Kotlin. (I have created a Kotlin wrapper - MUIRWIK), and in particular, for the question it is the MuiThemeProvider that provides the more or less globally accessible theme object.
Since the question was made, JetBrain released a wrapper library called kotlin-mui that brings Material Design UI to React components from MUI.
Related
I am totally new to creating extensions in VS Code, and all the official examples of extensions are written in Typescript/Javascript, which I have no experience with. Is it possible to create VS Code extensions in other languages, such as Python or C++?
If so, could anyone point me to any resources to get me started?
It is possible by creating a C++ module for Node.js, which can then be loaded like any other node module. Of course, some glue code written in JS or TS is necessary to register the extension and translate calls to/from vscode.
I've gone this way in my ANTLR4 extension, but gave up eventually, because of the troubles I had due to incompatible dependencies (you have to make sure the extension uses the exact same V8 version, which was used to build the underlying Node.js used by vscode, on all supported platforms).
This situation might have change, I don't know, but with that in the background I don't recommend it.
If you want to add support for a new language in vscode you can also write a separate language server, as is mentioned in the linked SO answer. For other type of work, I'm afraid, you have no alternative to use.
No, as #rioV8 said, since VSCode is an electron app and runs on Javascript.
The title already says it and we do have a working example. However, the library we have built does have it's own customTheme and uses styles to such an extent that we cannot just copy them to the projects importing the library.
Right now we do get the following error on multiple developer machines:
It looks like there are several instances of #material-ui/styles initialized in this application.
This may cause theme propagation issues, broken class names, specificity issues, and makes your application bigger without a good reason.
See https://material-ui.com/r/styles-instance-warning for more info.
Is there a best practice for creating Material-UI components in a library which can then be reimported into other projects with its styles and everything of course then inheriting colours etc. from the project the library is imported to.
I am new for ReactJS. Should I go with JSXTransformer or Babel for writing ReactJS code?
I understand that ReactJS implementation is not depend on JSXTransformer / babel. We can use ReactJS without these two too, but still I want about this with respect to ReactJS.
This is opinion based so should probably be closed.
Pretty sure the React team have deprecated the use of the JSX Transformer (outside of in-browser development usage) in favour of Babel. Babel now supports everything that React needs (and more) in a convenient and standard way and should be considered the preferred method of JSX transformation.
More information on React tooling can helpfully be found at their tooling page.
Matt Styles is right, it's beeing deprecated:
from here
JSXTransformer is another tool we built specifically for consuming JSX
in the browser. It was always intended as a quick way to prototype
code before setting up a build process. It would look for
tags with type="text/jsx" and then transform and run. This ran the
same code that react-tools ran on the server. Babel ships with a
nearly identical tool, which has already been integrated into JS Bin.
We'll be deprecating JSXTransformer, however the current version will
still be available from various CDNs and Bower.
However it is great to learn the basic of react, focusing on component methods, passing props, etc.. with a easy integration.
But i believe you won't be able to require any node modules, wich will block you soon or later.
To learn React and the node environnement, I suggest you to make a few tutorials, and to test and read the code of simple boilerplates project like these:
react-hot-boilerplate
react-transform-boilerplate
I started working on projects in GWT last month. It was all well until I needed drag and drop(DND). After trying gwt-dnd library like everyone else I got infatuated by smart-gwt widgets. But everywhere I read that its a very thin wrapper over Javascript. But I've still decided to go with it. I have some general questions regarding GWT.
Is it okay to write the GUI in a mix of plain-GWT and smart-gwt ?
Can I implement drag and drop only with plain-GWT without the help of external libraries?
Should I write the smart-GWT like widgets in plain-GWT myself?
No you shouldn't and neither is proposed from the smartgwt creators, There are some tweaks that can make it work, but it is at a per case base ...
You could try to achieve this, especially with the latest 2.5 version and its Elemental library.
Depends what you need and the resources you have for the task. You could make look-like lighter elements macthing the smartgwt ones, but it can be tricky if you are looking after operations like filtering etc. Bottom line is, you wouldn't be considering the smartgwt or any other similar library, if you had the time and resources to develop its widgets.
I am upgrading a project with around 60 java classes, from 1.4 to 2.0 . Apart from replacing deprecated functions, adding generics, will converting the whole project into UI Binder approach i.e. XML and Corresponding working Java classes, be recommended. Or shall i go on adding new UI requirments using Ui Binder and leaving the existing code as it is?
I'd go with UiBinder all the way - that way you'll get most from the benefits of UiBinder (like nice CSS handling/minification/obfuscation). And the rewrite will be a good chance to look at the older code and do some refactoring - like reorganizing the Widgets to be more lightweight (more pure HTML via UiBinder, less Widgets, but don't go overboard ;)), maybe introducing History support, i18n, etc. I had the same dilemma some time ago and took the full UiBinder approach and don't regret it ;) It makes it easier to work with the code too - since the UI code is consistent.