Looking for maintainers

[andykog]

Hey, I don't have much time and interest to support this project lately so if somebody wants to maintain it — you're welcome!

[dleitee]

Hey @andykog, are you looking for maintainers yet? I'm free to contribute, can we schedule a call to discuss the project?

Thanks

[andykog]

Sure, please ping me in telegram: @andykog or in twitter: @andy_kogut

…

On Aug 20, 2019, at 19:52, Daniel Leite de Oliveira ***@***.***> wrote: Hey @andykog, are you looking for maintainers yet? I'm free to contribute, can we schedule a call to discuss the project? Thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[yuxizhe]

I am happy to maintain it @andykog 😄

[Venryx]

How much leeway would a maintainer have to develop new features?

There are a lot of feature ideas and usability improvements I would like to add to the devtools (and I have enough free time to implement many of them), but I'm weary of having to wade through too much code review and the like. (For libraries, I can understand extreme caution, since mistakes can break production code; but I think it's less important for developer tools, since developers understand the system enough to know how to debug if something goes wrong, and downgrade if necessary.)

I won't intentionally push code that I know introduces issues of course, but it's more a question of whether the implementation choices for new features is able to be done on an "implement first, standardize later" basis, or if instead it's required that we figure out those things ahead of time.

If the latter, an alternate approach I could take is just to create a fork named "mobx-devtools-plus" or something, code all the features there however I like, and then we can backport those features on a case by case basis, as the people here can take a look at what the feature does and how to best standardize around it.

Thoughts? @andykog (and whoever else holds swap in this repo XD)

[andykog]

@Venryx, maintainer would have unlimited leeway to develop useful features. If developer is not sure whether or not the feature is useful, he/she can discuss it with the community in gh issues. Having code reviews is a very good idea, especially for the first contributions, but nobody will be too strict about stuff like codestyle & test coverage if you’re worrying about that.

[Venryx]

Okay, sounds good.

For now I went ahead and made this fork: https://github.com/Venryx/mobx-devtools-advanced
I'll work there for now, so that I have maximum freedom to iterate quickly.

Once my "initial burst of development" is done, I'll try to form an overview of the changes I made, and present them here. The changes that seem acceptable to add to the main repo, I can then work on porting over.

I think most of the features will probably be worth adding to this repo, however I decided to build it in a (differently named) fork first, since I'm also changing other stuff -- like updating webpack, babel, etc. to the latest versions, and changing the whole project to TypeScript (bit by bit).

Because I'm not sure those more extensive changes would be desired in the main project, using a fork lets me not worry about those other changes while focusing on the new features. Once the intensity of my development evens off, I'll then look to porting the features themselves back to this repo.

If a high enough percentage of the changes are desired in this main repo, I can then discontinue my fork and just work here; otherwise I'll keep it going in parallel and release it as "MobX Developer Tools (Advanced)" or something on the Chrome store.

[auvipy]

I would love to be a co-maintainer. so when you are done ping me for review :)

[Venryx]

Updates:

• Converted all files (in src folder anyway) to TypeScript.
• Got basic displaying of component-tree working. (letting you view deep-dependencies of components)
• Made-so the Changes panel shows the actual old and new value -- even when the values are of a custom type -- for Actions that are logged. (instead of the infuriatingly detail-less "(SomeType)" string)
• Added UI to Changes tab letting you choose which types of changes you want to show in the Changes list. (greatly helps when trying to debug actions, without reactions filling up the list)
• Updated a ton of dependencies (webpack, babel, etc.) to their latest versions.
• Added "Collapse non-MobX" checkbox to components panel. (working, and enabled by default, for now)
• Changed the default/first-listed font to Roboto. (open source, and also has better alignment, ie. it doesn't have lots of extra space above text like Segoe UI) [latest]
• Added easy-to-understand error message for when two mobx instances are found in the page. (or rather, when it tries to process a change, where change.object.(the $mobx symbol) is different than collection.mobx.$mobx (the symbol))
• Added type-data for lots of various constructs.

Screenshot of component tree (very primitive atm):

Screenshot of change filtering by type:

[andykog]

@Venryx, looks awesome!

[rainmanhhh]

Updates:

• Converted all files (in src folder anyway) to TypeScript.
• Got basic displaying of component-tree working. (letting you view deep-dependencies of components)
• Made-so the Changes panel shows the actual old and new value -- even when the values are of a custom type -- for Actions that are logged. (instead of the infuriatingly detail-less "(SomeType)" string)
• Added UI to Changes tab letting you choose which types of changes you want to show in the Changes list. (greatly helps when trying to debug actions, without reactions filling up the list)
• Updated a ton of dependencies (webpack, babel, etc.) to their latest versions.
• Added "Collapse non-MobX" checkbox to components panel. (working, and enabled by default, for now)
• Changed the default/first-listed font to Roboto. (open source, and also has better alignment, ie. it doesn't have lots of extra space above text like Segoe UI) [latest]
• Added easy-to-understand error message for when two mobx instances are found in the page. (or rather, when it tries to process a change, where change.object.(the $mobx symbol) is different than collection.mobx.$mobx (the symbol))
• Added type-data for lots of various constructs.

Screenshot of component tree (very primitive atm):

Screenshot of change filtering by type:

when will these changes be released? there is no "Component" tab in current version (0.9.21)

[Venryx]

I became occupied with other work, so didn't finish preparing the changes for a pull-request to this main repo.

You can try out the new Component tab by compiling and installing my forked version locally: https://github.com/Venryx/mobx-devtools-advanced/blob/master/Docs/Hacking.md

Only tested on Chrome atm.

[Mowinski]

Hi @andykog :)

I am a huge fan of MobX and I've really missed your dev tools. But right now I am working as a consultant and also I feel so sorrow that I am not able to programming in my job right now. So my proposition is, I can bring to live your application.

My first goal will be fix the missed component and state tab in chrome. Is it okay for you?