Stable version

Hi there! I didn't spend enough attention to this project for a quite a while, but I can't ignore enormous amount of issues anymore. To make them approachable, I decided to start cleaning up the codebase we have nowadays. In my mind it is hard to make a good contribution if project doesn't even keep the same code style. Also, its pretty said to see things like module.exports in React Native modules in 2017.

Therefore, I started cleaning this project up by introducing a code style standard. Here is a list of current changes:

• Assembled https://github.com/airbnb/javascript to maintain one of the most common javascript code styles
• Assembled Flow to replace comments by types and improve developer experience overall
• Updated Basic example to use latest version of React/React Native

Breaking changes:

• Using ES module notation instead of commonJS one, e.g. from now on it should be

   import SideMenu from 'react-native-side-menu';

  instead of

  const SideMenu = require('react-native-side-menu');

  (yay! 🎉 )

0.18.0

Hey!

Thanks to @Kureev, @grabbou, @BasitAli we are presenting next version of side menu - 0.18.

Features

There were a couple of people complaining that menu can be dragged more than allowed sideMenuOffset. We now made this behaviour configurable - if you don't like it - simply set bounceBackOnOverdraw to false.

We now also align better with the rest of existing ecosystem by not restricting react-native version inside peerDependencies.

Note to developers: Our examples now run master version directly instead of getting it from npm which speeds up development significantly as we always get latest preview of menu. We hope this will make you even more excited about contributing!

Fixes

There were a couple of complaints about scrollsToTop behaviour on ScrollViews not working properly when using SideMenu. This is due to iOS implementation detail that we have described in our FAQ section.

Upgrading notes

No actions need to be taken when upgrading from previous release (0.17.2). Component has been tested in production applications with latest React Native version (0.17) and no issues were found.

General code clean-up

Hey folks!

It was a really busy time, but seems I've managed to find some for react-native-side-menu. In this release I've mostly concentrated on deprecating menuActions, context etc. I'm also planning a next step to move out a draggable behavior to standalone function. It'll make possible to use it like this:

const DraggableSideMenu = makeDraggable(SideMenu)

But that's a small spoiler for the upcoming x-mas major release. Let's now focus on the current one:

Deprecating menuActions

A while ago I've introduced a menuActions to manage side menu's state. Then we felt into some pitfalls with a way passing them down (thru props or context). Well, I didn't like using plain props, because you can't pass them to Nth child without having a lot of boilerplate in your code. So, at some point I decided to use a context for this purpose. Unexpectedly, some of people started to complain about using context (experimental feature + some "magic" in the code). Well, I'm agree, but it seems to be a lesser evil.

So, I though about it for a while and find out that we can actually remove a menuActions object (:open_mouth:). Instead, I propose to use a plain prop on SideMenu component (isOpen) and it's as simple as

<SideMenu menu={<Menu />} isOpen={true}>
  <Content />
</SideMenu>

How you'll provide isOpen flag to component - it's up to you. Personally I use redux library for my data flow, but for sure you can use something else.

Deprecating touchToClose

When I started to develop this component I had no clue how it should really behave. Eventually, @skevy submited a nice PR to add touchToClose feature. I think it's a too cool functionality to keep it under a flag. As far as I can't imagine any real valuable example of not using it, I decided to put it as a default behavior in this version 💃 .

Deprecating defaultOpen

Well, now we have an isOpen flag, so why should we keep this one? I think it did a trick pretty well, but now it's not even needed, so RIP, defaultOpen 💀

Conclusion

v0.15.2

Fixed

• #127
• #107

`menuActions` refactoring

Last few days I received a lot of issues from users about accessing menuActions from child content view components. I admit, that previous solution had a bunch of edge cases I was supposed to fix and now I'm glad to present you a result of my work trying solving these issues.

Now you're able to use context (I think it's already well-known feature of React, even besides it's not documented yet), so instead of using props' menuActions property on the first-level component you're able to use context's menuActions property which is available across the all child views. Example is already there, you can check a README for it.

Related issues:
#101
#99
#96

Hope that will hope you to build even more awesome software!

Responder control

• Exposed onStartShouldSetResponderCapture #94
• Added support for 0.11.0-rc #95

Animate all the things!

• Replaced LayoutAnimation by Animated and exposed animationFunction to create your own fancy animations for open/close methods and animationStyle function to declare your animation logic;
• Fixed usage of Dimensions, now you wouldn't receive annoying notifications about it;
• Updated README.md with new API description