Giter Club home page Giter Club logo

mobx-logger's People

Contributors

cranesandcaff avatar mohsen1 avatar npmcdn-to-unpkg-bot avatar winterbe avatar xxsnakerxx avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mobx-logger's Issues

TypeScript definition file

A lot of people are using MobX with TypeScript. Can you provide a embedded .d.ts file?

โค๏ธ

Confusing default and named export

This package is awesome :)

This threw me off on a quick debugging journey, from the README:

import {enableLogging} from 'mobx-logger';

// optional
const config = {...};

enableLogging(config);

Since enableLogging is imported by name, I expected this to work:

import mobxLogger from 'mobx-logger'

mobxLogger.enableLogging()

And that threw an error, since both the default export and named export are the same:

// mobx-logger/src/index.js

export const enableLogging = (options = defaultOptions) => {
    const predicate = options.predicate || defaultOptions.predicate;
    if (predicate() === true) {
        return spy(ev => log(ev, options));
    }
    return () => void(0);
};

export default enableLogging;

This is the first time I encountered such exporting convention.

I would change either the named or default export, as long as they are not the same.

Thoughts?

I'll gladly prepare a PR, mobx is awesome! ๐Ÿš€

Log function name for computed values

Since 0.4.0 logging of computed values is suboptimal because the function name is no longer accessible from spy events in Mobx 3.

Try: extras.getDebugName(event.fn)

[Feature Request] Filtering logging events

Hi

I think it should be fine if we can define in config object filters for Mobx events.

So properties of the config object can accept boolean or callbacks.

This should help avoid situations in ReactJS, where console has a lot of reactions on component's renders.

For example:

enableLogging({
  reaction: (e) => !e.name.includes('render'),
  action: true,
  transaction: true,
  compute: true,
});

Transaction name isn't logged

I'm getting %s in my console instead of the transaction name:

21:31:08.725        TX  %s
21:31:08.732    ACTION  GridStore.setOptions()
21:31:08.739    ACTION  GridStore.setData()
21:31:08.754        TX  %s

Looks like the name wasn't passed to groupCollapsed in log.js - line 31 - adding it as the last arg seems to fix it ๐Ÿ‘

console.groupCollapsed('%c%s  %s  %s', style('#7B7B7B'), now(), padStart('TX', 8), ev.name);

implement predicate in web

Very cool logger :)

Would be great to change the predicate on the fly for debugging production. Is that possible? Should I send a PR?

This is what I want to do:

enableLogging({ predicate })

function predicate() {
  return window.__MOBX_LOGGER__
}

and then can do window.__MOBX_LOGGER__ = true in the console

MobX Logger causing performance issues in Safari

Hi there,

We're running into some issues with MobX logger and Safari (v 11.1.1). Whenever it is enabled it's causing the browser to hang when loading the app and making changes to MobX stores.

Our enableLogging currently looks like this:

    enableLogging({
      predicate: () => true,
      action: true,
      reaction: false,
      transaction: false,
      compute: false
    });

Happy to do some testing to figure this out!

Plain Logging option

Hi-
I'd like a very simple logging format for when output is going to the Terminal (from unit tests). Would you be open to a PR with an option {plain: true} ?

Just simple stuff like -

var logAction = function logAction(ev) {
    if (!isLoggingEnabled(ev)) {
        return;
    }
    console.log(ev.type +" "+ ev.name + " " + JSON.stringify(ev.arguments));```

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.