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?

[andykog]

Hi @Mowinski, sure, would be nice!

[andykog]

Hi, @acqyzz, looks awesome! Cold you show the code? You can contact me in telegram: @andykog

[coolsoftwaretyler]

Hey folks, I'm one of the maintainers over at mobx-state-tree and I'm very interested in supporting the broader MobX ecosystem.

I'm focused on MST for the foreseeable future, but if there are small tasks I can assist with, please let me know. My email is in my GitHub profile.

[listepo]

@andykog any news?

[andykog]

@listepo nope, there were a few people who showed interest in this thread but no actual PRs
@coolsoftwaretyler I'm not using mobx / mobx-devtools for years, not even sure if the devtools support the latest mobx. Checking/fixing it would be a great start

[coolsoftwaretyler]

I'll take a look this week!

[coolsoftwaretyler]

Hey @andykog - I got started looking around, but there's a ton of stuff that's breaking just in the local setup. I submitted a quick PR for the first blocking issue I hit, but it's gonna be slow going.

I am happy to keep working on this, but I get the sense you are no longer interested. Do you have capacity to review PRs, or any interest in giving me some more permissions so I can work on it more directly?

I can reach out on Telegram if it's easier for you to coordinate that way. Let me know.

[andykog]

Thanks @coolsoftwaretyler! You have access, also I can review PRs asynchronyosly & publish new versions to chrome/firefox stores (it used to happen automatically in CI but this integration doesn't work anymore I think)

[coolsoftwaretyler]

Awesome, thank you!

I will prioritize getting a dev environment set up and new documentation. That way we can make it a little easier for people to contribute (myself included). Will put some time in over the next few weeks on this.

[coolsoftwaretyler]

Recently made some progress here. If anyone else wants to help out, let me know. My email is in my GitHub or we can coordinate here/in other issues and PRs.

[coolsoftwaretyler]

I also put together a milestone to categorize some of the issues that we need to address before we can really get to the existing issues/PRs, since the codebase is somewhat old. Check it out if you want to pitch in: https://github.com/mobxjs/mobx-devtools/milestone/1

Once we enumerate and complete these tasks, we can start getting around to the actual issues. Reach out if ya need anything!

[coolsoftwaretyler]

Almost done with #120, at which point I think we can really facilitate PRs for the small bugs, feature requests, and new ideas. Will update here once that's locked in.

[coolsoftwaretyler]

Ok, 2024 dev readiness is complete.

At this point, I think we're ready for contributions from a wider group of people. I have a better handle on the codebase myself, and should be able to help onboard new contributors to tackle the rest of the list.

Now that things are a bit more modern, I'm going to scale back and re-focus my OSS efforts elsewhere, but I intend to be available and active whenever other people are interested in keeping this project moving forward.