The typical smart mirror film is Gila mirror window film (https://www.amazon.com/Gila-Privacy-Adhesive-Residential-Control/dp/B000H5XTKG). I got mine from Lowes in the U.S. It is a lot cheaper than two-way glass, and the quality isn’t mind-boggling but it’s not bad either. I think it’s 30% transparent but you can check that through the link. I applied my film to acrylic and it worked well enough–I’d recommend it if you’re on a budget.

@sdetweil I just want to recommend the execa package as it solves some issues with “child_process,” like cleaning up when the process exits.

@BKeyport Here’s a more detailed explanation for you and anyone who is curious.

The if (typeof module !== "undefined") {} line checks if there is a global variable named module. If there is, then we must be using a module system and we have to export config using module.exports = config;. If not, then we must be in the browser and config will already be available to any other modules.

In the browser, there is no concept of separate modules (a.k.a. files); script files are loaded in and simply concatenated one after the other. So if you load config.js and then another-file.js, the config variable (var config = { ... } ) will be available as a global variable in another-file.js. The module and require variables are not defined.

In more modern code with a module system, you have to export anything you want to use elsewhere, and import it in modules where you need it. Node.js uses module.exports = ... to export and ... = require("module-to-import") to import.

You’re right, I forgot about the if (typeof module !== undefined) check. It might work if you set electronOptions: { nodeIntegration: true } in the config, but I haven’t tested it.

Another way to do this would be to create a config/secrets.js file containing your secrets, making sure to add it to the .gitignore so that it doesn’t get publicly committed to GitHub. Then you can require it from your config/config.js file.

// config/secrets.js
module.exports = {
  weatherApiKey: "key"
};

// config/config.js
var secrets = require("./secrets");
var config = {
  // your config
}

I’m working on an experimental version of MagicMirror decribed here and with that comes the opportunity to make a new and improved NodeHelper (backwards compatible of course).

I’m wondering what issues people are having with the current NodeHelper, if any. Are parts of the API difficult to use or understand?

Possible improvements might be using the ES6 class syntax, adding or adjusting subclassable methods, or changing other things. Thanks for your thoughts!

@ezarlive it uses a fork of create-react-app under the hood so all of the same features (and ones that come out in the future) will be there. Hoping to make developing a module a perfect starter project for people interested in React.

In any case, it will probably be available first as a separate repository, for ironing out bugs.

I’m debating whether to “hide” a lot of the code by putting it into an installable npm package, to leave it all in the repository, or somewhere in between. What’s more important: allowing users to see all of the code easily, or keeping it simple by hiding some of the complexity under the hood?

@BKeyport You mean merging these new features into the original project? Theoretically it should be possible, but as it comes with significant internal changes, it would be up to Michael. In the long run, it might be best to merge them so that the new React modules could work for current MagicMirror users, but this will be experimental for some time.

Maybe it could live on another branch so users could type git checkout experimental to opt into the new features.

Hi all,

I’m currently working on expanding what MagicMirror can do, using the React library and all of the modern tools available today.

Big fan of MagicMirror here–I just completed my first smart mirror, a full length standing one, and I like it a lot. But as a web developer in 2019, I’ve seen how convenient a modern setup can be. Every time you update a file, the display updates instantly, without having to restart. When source code has errors, it’s displayed to the screen, with help on how to fix it.

At the same time, the Magic Mirror manifesto makes it clear how much it values accessibility and simplicity, and the last thing I would want to do is change that. But with the rise of create-react-app, you can write React applications without worrying about any configuration! And, module developers can use TypeScript, Sass, and the newest JavaScript features to help them make powerful modules faster than ever before. Most importantly, a user can “open just one file and make a small modification and see how it works out.”

It’s easy to see that the wide array of available modules is what makes this project so interesting, so existing modules will work. Copying over a config.js will work as well. The draw to this version, hopefully, will be easier module development and faster rendering and reloading.

I’m interested to hear what people think of the idea, so any thoughts are appreciated. Thanks!