Perry is still not stable enough to actually be used in projects using AMD strategies such as Require.js.

This issue aims to track the development and stability of this in Perry.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

https://github.com/marketplace/actions/github-action-for-npm

I try to use perry js in a new HTML file and I get some error. This is my first time to use perry js. I import perry js from this link https://perry-js.netlify.com/bundle.js.

All links and javascript code I got from copy it from the perry js README.md.

This is the error message I receive

Error: [Perry Options]: "plugins" was supposed to be of type "array", but received "function ConsoleLogPlugin(reportInfo) {
console.log('[Perry Report Info]:', reportInfo);
}"

This is the full code of the javascript

function ConsoleLogPlugin(reportInfo) {
  console.log('[Perry Report Info]:', reportInfo);
}

const perry = new window.Perry({
  /* Enables log recording */
  log: true,
  /* Enables click recording */
  clicks: true,
  /* Enables screen recording */
  enableScreenRecording: true,
  /* Plugins are ways to handle the bug reporting submission */
  plugins: [ConsoleLogPlugin]
});

(async () => {
  await perry.render();
})();

Could anyone help me to solve this problem?

CodeFactor found multiple issues:

Trailing whitespace

src\packages\listen-window-errors\index.ts:21
src\packages\write-to-store\index.ts:10
src\components\WidgetIcon\index.tsx:16
src\packages\render-widget\index.tsx:1
src\interfaces\WidgetProps.ts:5
src\packages\map-html-element-to-element-data\index.ts:4

I've selected index.ts.listenWindowErrors for refactoring, which is a unit of 28 lines of code. Addressing this will make our codebase more maintainable and improve Better Code Hub's Write Short Units of Code guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Limit the length of code units to 15 lines of code.
• Why❓
  Small units are easier to analyse, test and reuse.
• How 🔧
  When writing new units, don't let them grow above 15 lines of code. When a unit grows beyond this, split it in smaller units of no longer than 15 lines.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

We can use Netflix PollyJS to record requests and be able to replay them when starting a perry recording session.

https://github.com/Netflix/pollyjs

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Goal

The goal of this issue is to track the design and development of a new client-side store for Perry.

Motivation

Today making some tests with the new feature in #47, I got this error while testing it:

Uncaught DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'perry::document.onclick::history' exceeded the quota.
    at writeToStore (webpack-internal:///./packages/write-to-store/index.ts:13:18)
    at HTMLDocument.document.onclick (webpack-internal:///./packages/listen-document-clicks/index.ts:21:108)

Basically it seems that WebStorage is limited to 10mb. (src: https://www.html5rocks.com/en/tutorials/offline/quota-research/)

Possible solutions

@JackTheRipper already proposed a couple of days ago to move to IndexedDB since now we have to also store blob's in the client for a while (the screen recordings).

In MDN they state IndexedDB as the following:

IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs. This API uses indexes to enable high-performance searches of this data. While Web Storage is useful for storing smaller amounts of data, it is less useful for storing larger amounts of structured data. IndexedDB provides a solution.

IndexedDB indeed looks way more solid for our purpose since we can generate a lot of data in a small period of time.

Maybe we can use it together with something such as https://localforage.github.io/localForage/ for fallback in browsers that don't support it.

There might be other solutions as well and this issue is a place to discuss those when they come on mind.

FYI @vitormargis @guilhermelimak

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I've selected index.ts.aggregateReport for refactoring, which is a unit of 16 lines of code. Addressing this will make our codebase more maintainable and improve Better Code Hub's Write Short Units of Code guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Limit the length of code units to 15 lines of code.
• Why❓
  Small units are easier to analyse, test and reuse.
• How 🔧
  When writing new units, don't let them grow above 15 lines of code. When a unit grows beyond this, split it in smaller units of no longer than 15 lines.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯

We are currently having problems integrating into our CI due to mismatches between preact API and a few dependencies we have.

Rebass used to work well with Preact before 3.x was released and made use of features like React.forwardRef which are not available in preact-compat.

Also, styled-components nowadays makes use of React.createContext, which is also not available in preact-compat.

(Even tho the preact team is working in Preact X, which will make this features available, is still in alpha stages and we cannot rely on it.)

So this issue aims to track the development of the few components the Perry Widget actually needs in order to work.

I suggest moving to https://github.com/emotion-js/emotion since it seems to use a more agnostic approach for CSS-in-JS.

Here is a checklist so we can track this better:

Primitives

• <Modal />
• <Button />
• <Input />
• <Label />
• <LabeledInput />
• <Form /> (I don't think we need something such as Formik for Perry)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

As perry grows, it will eventually get more and more bloated.

And even though some users can actually just add perry with everything on it and enable/disable features, they should also be able to choose whether they want to actually load those extra modules or not.

This issue aims to track the discussion and development of modular architectures for Perry's features.

Firebase for example offers a single way of using it all, and a more pluggable way where you can actually import the core of it and other modules as you need (e.g.: you can import only the auth module if you're not using the database at all)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I've selected index.ts.applyConsoleProxy for refactoring, which is a unit of 18 lines of code. Addressing this will make our codebase more maintainable and improve Better Code Hub's Write Short Units of Code guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Limit the length of code units to 15 lines of code.
• Why❓
  Small units are easier to analyse, test and reuse.
• How 🔧
  When writing new units, don't let them grow above 15 lines of code. When a unit grows beyond this, split it in smaller units of no longer than 15 lines.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

We can use https://github.com/yaronn/GifW00t to record the webpage interactions while the user uses the webpage, and also send them with the report.

This can also be well integrated with firebase through perry-firebase so we can also have nice interaction in the web panel =)

This issue aims to track the implementation of TSLint checks in this repository.

Currrently according to CodeClimate we have 461 linting issues in Perry.

Problem

Currently we cannot catch external script errors due to cross-origin policies in the browser. We currently also offer an option through the API in order to disable catching those errors (since we cannot catch them specifically)

Though, it seems that by using output.crossOriginLoading: 'anonymous' in webpack configuration you might be able to actually catch those in a valuable manner. (check https://webpack.js.org/configuration/output/#outputcrossoriginloading)

This issue aims to investigate the possibility of such feature

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

As we already have our Acceptance Links from Netlify, and also Travis CI getting integrated, perhaps we could start running some End-to-End tests using BrowserStack for Perry.

We can apply for an Application Form in BrowserStack to run our e2e when needed https://www.browserstack.com/open-source

Even tho, this issue is here mainly to track the development of the end-to-end project and their use cases inside using WebDriver.io with Cucumber.

We should discuss in order to define the flows we want to test in regarding to perry, but I do believe is going to be quite simple since it's UI don't have many features yet.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Right now we don't have any identifiers on reports, it would be nice if we could generate a GUID on the client and keep the report ID consistent on all plugins.

We could use this function as a base and reinforce on the docs the need for checking for duplicates before saving the report, just to make sure.

What do you think @armand1m?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Loads of packages still miss unit tests. They're easily testable thou.

This issue is to track unit tests missing in the packages namespace.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Nowadays Perry has the official deployment preview we use also for development in Netlify.

I would love to see some enhancements on that side too, mostly in regards to:

• Example demonstration
• Hyperlink and semantics
• UX Enhancements
• Sexyness (CC @JackTheRipper xD)
• Be able to provide information in a meaningful way

I've been thinking in maybe creating a Docusaurus page for it and deploying it, but also got kinda curious if maybe building our own website for this would be a good idea =)

This issue aims to track the development of this.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Convert interfaces to use convention like IMyObject instead of just a plain name.

Fix these lines:

Redux supports middlewares for injecting behavior into it.

It would be nice if we could offer a package for actually capturing redux actions and state into perry store so we can also export them later in the report.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

I've selected index.style.ts for refactoring, which is a unit of 50 lines of code. Addressing this will make our codebase more maintainable and improve Better Code Hub's Write Short Units of Code guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Limit the length of code units to 15 lines of code.
• Why❓
  Small units are easier to analyse, test and reuse.
• How 🔧
  When writing new units, don't let them grow above 15 lines of code. When a unit grows beyond this, split it in smaller units of no longer than 15 lines.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Some things in the actual implementation are diffing from the docs specifications, such as:

• Optional firebase interaction
• Plugin system
• New options such as clicks

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Basically, Perry is already good when it comes to dealing with unhandled exceptions, but when we deal with handled exceptions, the user might feel a need to report those as well, as they might be from external services being consumed and in various other scenarios.

Consider this block of code as an example of an actual usage for this feature:

try {
  someDangerousFunction()
} catch (e) {
  Perry.notify(e)
}

Today, 28-6-2018, we have a living prototype in Figma https://www.figma.com/file/dPeyZlkwtoF9ZN0FCTvwtZhP/Untitled.

And a living deployment of the Example page:
https://perry-js.netlify.com

However, this prototype and the actual implementation are diverging, and in this case we can consider the prototype as quite deprecated.

The main objective of this issue is to track the development of a design system for the tool.

But also, to track the development of a defined user flow design system that our implementation must comply.

This will help us build a better project as it will offer a well design user experience.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Right now we have no way to access the types on this repository from outside, to solve that I think we should move the types to a repository of their own and import it here and wherever else is needed.

We could also set up all repositories as a scoped monorepo and use lerna to manage it to make it a bit less painful.

For now Perry is recording every single click of the application when it is instantiated.

This behaviour is due to the hooks set in these lines:
https://github.com/perry-js/perry/blob/master/src/packages/perry/index.ts#L57-L59

Now, these hooks should move to the Widget component. It can be assigned to it through the props object in the same file, at the render() method.

Instead of just:

    const props: WidgetProps = {
      onSubmit: (reportInfo: PerryReportInfo) => {
        const report = aggregateReport(reportInfo);

        options.plugins.map(plugin => plugin(report));

        return report;
      }
    };

It will be:

    const props: WidgetProps = {
+     onStartRecording: () => {
+       // subscribe
+       clearStore();
+       applyConsoleProxy(options);
+       listenWindowErrors(options);
+       listenDocumentClicks(options);
+     },
+     onStopRecording: () => {
+       // unsubscribe
+       removeConsoleProxy(options);
+       removeWindowErrorsListener(options);
+       removeDocumentClicksListener(options);
+     },
      onSubmit: (reportInfo: PerryReportInfo) => {
        const report = aggregateReport(reportInfo);

        options.plugins.map(plugin => plugin(report));

        return report;
      }
    };

Basically these hooks need to be modified to allow them to be unsubscribed as well. The following methods will need to be created within the PR:

removeConsoleProxy(options);
removeWindowErrorsListener(options);
removeDocumentClicksListener(options);

Also, the <Widget /> component will have to adapt to these new props, and actually run the subscription handlers when it changes its states in the nextStep instance method.

https://github.com/perry-js/perry/blob/master/src/components/Widget/index.tsx#L32-L41

  nextStep = () => {
    switch (this.state.status) {
      case WidgetStatus.IDLE:
+       this.props.onStartRecording();
        return this.setStatus(WidgetStatus.RECORDING)
      case WidgetStatus.RECORDING:
+       this.props.onStopRecording();
        return this.setStatus(WidgetStatus.STOPPED)
      case WidgetStatus.STOPPED:
        return this.toggleModal()
    }
  }

The WidgetProps interface will also have to change.

https://github.com/perry-js/perry/blob/master/src/interfaces/WidgetProps.ts

export default interface WidgetProps {
  status?: WidgetStatus;
+ onStartRecording: () => void,
+ onStopRecording: () => void,
  onSubmit?: (info: PerryReportInfo) => void,
};

Roadmap

• Add recording methods to component handler
• Add stopping methods to component handler
• Restore console to default window value when stopping
• Stop listening for window errors when stopping
• Stop listening to document clicks when stopping

Perry currently is only used as a bug reporting tool, but in its own nature, it is basically a fancy log and activity watcher for a web page, and it should be able to keep running without any UI in the background listening to interactions in the page and notifying a server constantly.

This issue aims to track the ideas for this features and also it's development.

I've selected onclick for refactoring, which is a unit of 37 lines of code. Addressing this will make our codebase more maintainable and improve Better Code Hub's Write Short Units of Code guideline rating! 👍

Here's the gist of this guideline:

• Definition 📖
  Limit the length of code units to 15 lines of code.
• Why❓
  Small units are easier to analyse, test and reuse.
• How 🔧
  When writing new units, don't let them grow above 15 lines of code. When a unit grows beyond this, split it in smaller units of no longer than 15 lines.

You can find more info about this guideline in Building Maintainable Software. 📖

ℹ️ To know how many other refactoring candidates need addressing to get a guideline compliant, select some by clicking on the 🔲 next to them. The risk profile below the candidates signals (✅) when it's enough! 🏁

Good luck and happy coding! ✨ 💯