help menu

Join us on the Community Forums!

  • Community Guidelines

    The Fitbit Community is a gathering place for real people who wish to exchange ideas, solutions, tips, techniques, and insight about the Fitbit products and services they love. By joining our Community, you agree to uphold these guidelines, so please take a moment to look them over.

  • Learn the Basics

    Check out our Frequently Asked Questions page for information on Community features, and tips to make the most of your time here.

  • Join the Community!

    Join an existing conversation, or start a new thread to ask your question. Creating your account is completely free, and takes about a minute.

Not finding your answer on the Community Forums?

Cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

My example of using third-party ES modules (lodash, redux)

‎10-28-2017 09:13

‎10-28-2017 09:13

Obviously big things are not a good idea for memory, but new style ES style imports are all about being able to be used anywhere and hopefully the treeshaking works.

 

https://github.com/kencaron/fitbit-os-redux-clock

 

Here's what I did. I installed redux into an empty directory using npm and copied over it's `src` into a new dir in Fitbit Studio `common/modules/redux@3.7.2`. The 3.7.2 is just to keep things straight in case I really want to do a manual update.

 

In my `app/index.js` I tried to import Redux's createStore and got it working with

 

import { createStore } from '../common/modules/redux@3.7.2/index.js';

To get the build to run I just tried to solve all of the missing path errors. For instance in `common/modules/redux@3.7.2/createStore.js` there was a line that imported "lodash-es/isPlainObject".

I made a lodash-es dir and copied individual files over from the local npm project's node_modules until it stopped complaining.

 

This is not an ideal workflow and would not be practical with a large library, but I can see it being very helpful for people to know how to import lodash into their project.

 

Next step is to try to build the app in in a clean way with a proper dir structure: actions, reducers, etc.

 

Yes this is all very academic and may beg the question of "but why?" especially without the index.gui being able to support anything react like. But I'm learning redux and thaving fun with the Ionic so I thought I'd share.

Best Answer
2 REPLIES 2

‎10-30-2017 07:13

‎10-30-2017 07:13

Thanks for the post.  This (working with the Ionic) has been a good exercise in rethinking my tendency to rely on libraries to solve problems, as the limited space causes you to really evaluate how much "fluff" is included in most libraries.

 

Did you happen to pull down the app package after the tree shaking to see how well it worked?

Best Answer
0 Votes

‎10-30-2017 07:50

In response to BayssMekanique

‎10-30-2017 07:50

@BayssMekanique Absolutely. JS is a double-edged sword here with the ever expanding size of web-apps.

 

The final `app.js` from download my app seemed to be 8kb and did seem to shake out quite a bit. For instance no reference to redux's applyMiddleware which I didn't import but it sitting there in my common/modules/redux dir.

 

In my simple example, introducing Redux increased my JS memory (as read from system.memory.js) by about 13% over a minimal app that simply logs "hello world".

 

For it's small size and limited dependencies, Redux seemed like a good candidate for an experiment like this.  I'd be curious to see what other new "modular ES" libraries work well. date-fns comes to mind for people that need moment.js type stuff.  Warning though. I advise against dragging a dir like that into studio with dozens of subdirs and files. I crashed chrome. Try to only import what you really need.

Best Answer