Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrating with wix/react-native-navigation #61

Open
kkjdaniel opened this issue Nov 10, 2017 · 11 comments
Open

Integrating with wix/react-native-navigation #61

kkjdaniel opened this issue Nov 10, 2017 · 11 comments
Labels

Comments

@kkjdaniel
Copy link

Our app is using wix/react-native-navigation which as per the diagram below changes the implementation of the app. Which means, wrapping the app under a single shared Tester component doesn't work in the same way.

687474703a2f2f692e696d6775722e636f6d2f53697978304a552e706e67

Just wondering if anyone here has any ideas or solutions to this?

@jalada
Copy link
Contributor

jalada commented Nov 14, 2017

Hmm interesting. There's not really going to be a solution for that. Cavy is really designed to be in pure React Native land, and so react-native-navigation is fairly incompatible with Cavy.

That's a shame, but I don't have an answer for how we could support it right now.

I'll leave this issue open for now.

@kkjdaniel
Copy link
Author

@jalada Fair enough, I think for now, I will look into other methods of testing. Thought I would at least put this here for anyone else that has a similar experience. Thanks for responding!

@jalada
Copy link
Contributor

jalada commented Nov 14, 2017

@kkjdaniel thank you for reporting it! It's useful to know what libraries people are using and trying to use Cavy with. Appreciate it 🌟

@jalada jalada closed this as completed Dec 20, 2017
@jalada jalada reopened this Dec 20, 2017
@padupuy
Copy link

padupuy commented Aug 2, 2018

@jalada when you register your screen, wrap it with a HOC. You need to repeat this operation as often you have screens

import { withE2E } from './hoc';
import AppSpec from './specs/AppSpec';


  Navigation.registerComponent(CONSTANTS.SCREENS.LOGIN.id, () =>
    withE2E(LoginScreen, AppSpec)
  );

the code of withE2E HOC

import React, { PureComponent } from 'react';
import { Tester, TestHookStore } from 'cavy';

const testHookStore = new TestHookStore();

export default (WrappedComponent, ...specs) => {
  class Enhance extends PureComponent {
    render() {
      return (
        <Tester
          clearAsyncStorage
          specs={[...specs]}
          store={testHookStore}
          waitTime={4000}
          startDelay={1000}
          sendReport={true}
        >
          <WrappedComponent {...this.props} />
        </Tester>
      );
    }
  }

  return Enhance;
};

@danielgreane
Copy link

Hey @padupuy , did you have any luck with this solution?
I imagine this would bootstrap multiple instances of cavy, however I'm wondering if elements for each instance would be able to reference each other, as when navigating to another screen that has a separate set of elements within it

@MrLoh
Copy link
Contributor

MrLoh commented Jul 17, 2020

You'd need to have a single test runner and test hooks store. From looking at the Codebase this wouldn't be possible with the tester, but you could simply build your own component that is similar to tester from providing the cavy context and then star the test runner imperatively. I'm not using react native navigation anymore, but cavy has a pretty easy to understand and small Codebase, so extending it to this use case should be easily possible, if you are experienced enough.

@freerangenerd
Copy link

I'm investigating Cavy for potential use in apps at my company. Kind of surprised this isn't addressed in the docs for alternative use cases, to encourage adoption.

@jalada
Copy link
Contributor

jalada commented Aug 28, 2020

@freerangenerd Apologies I'm not quite sure I understand your comment. What do you mean by 'addressed in the docs for alternative use cases, to encourage adoption'?

@freerangenerd
Copy link

I'm referring to MrLoh's comment.

I'm evaluating Cavy for use by a wide range of teams. This issue, asked three year ago, asks what to do if you have multiple RCTRootViews. It seems like a very reasonable use case to me. Not that Cavy has to support it, but if it aspires to wide-scale adoption like Detox, IMO, it should eliminate developer friction for this use case. So, it surprises me that the documentation doesn't cover it.

A single app developer may decide to invest time to solve the problem so they can try out Cavy. Others may just gloss past it.

As I look at whether to recommend Cavy to a wide array of teams, I'm asking questions, like How well has it been supported? How hard is it to integrate? Does it impact performance?

  • I see this issue for teams using a navigation system like the developer here.
  • It looks like it is well supported, though @types/cavy is not up to date currently.
  • For our use, I'm thinking this requires generating a bundle variant of its own to avoid growing the bundle size in production. This would also avoid performance cost loading at launch.

@jalada
Copy link
Contributor

jalada commented Sep 1, 2020

Thanks @freerangenerd. Basically, you think the docs (cavy.app) should include something about wix/react-native-navigation, because you believe it's a common ask? Where would you have expected to find that information in the documentation? Perhaps the FAQ page?

And you also think perhaps we should find a way of supporting it. As mentioned above, because wix/react-native-navigation is a mixture of native and non-native code, it kinda sits beyond Cavy's remit (pure-JS land). That said, if we get some time to explore it ourselves, we'll update this issue with what we find.

@freerangenerd
Copy link

I'm not concerned with wix/react-native-navigation in specific. That is just one possible way of hitting the problem. I'm concerned with handling multiple root views. There are other reasons (overlays) why you might have more than one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants