Looking for a new maintainer!

[boygirl]

This project is in need of a dedicated maintainer. We take open source maintenance seriously, but we don't have the bandwidth to give every one of our projects the support it requires to move forward. We are actively looking for new project maintainers. Please let us know if that might be you! We are happy to help new maintainers transition onto the project, and we are open to any infrastructure or process changes that could make that transition easier.

[boygirl]

@bingomanatee any interest?

[bingomanatee]

I’m open to it - but can you give me a sense of how broadly Freactal is being used?

Sent from my iPhone

On Oct 31, 2018, at 3:21 PM, Lauren notifications@github.com wrote:

@bingomanatee any interest?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[boygirl]

The usage is currently quite low (as judged by npm downloads), but we would put some marketing support behind it if someone was passionate about moving the project forward.

[bingomanatee]

Right now it is using the deprecated version of Context. Let me see what kind of work it requires to pull it into the 16.x context of React.

On Nov 1, 2018, at 11:15 AM, Lauren notifications@github.com wrote:

The usage is currently quite low (as judged by npm downloads), but we would put some marketing support behind it if someone was passionate about moving the project forward.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormidableLabs/freactal/issues/112#issuecomment-435131994, or mute the thread https://github.com/notifications/unsubscribe-auth/AApv8ACGXAq7eIbCFHe6g5qNQlbn_8Glks5uqzpfgaJpZM4YFdj0.

[boygirl]

Thank you! I have also reached out to @julien-f who maintains a fork of this project called Reaclette.

[bingomanatee]

So — this is very rough but — with Context I think I have got 90% of Freactal in c. 60 lines of code.

https://github.com/bingomanatee/freactal-rebuild https://github.com/bingomanatee/freactal-rebuild

On Nov 1, 2018, at 1:44 PM, Lauren notifications@github.com wrote:

Thank you! I have also reached out to @julien-f https://github.com/julien-f who maintains a fork of this project called Reaclette https://github.com/JsCommunity/reaclette.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormidableLabs/freactal/issues/112#issuecomment-435180692, or mute the thread https://github.com/notifications/unsubscribe-auth/AApv8KQbMBtLbY-3wx-zHxJxoG6N8M9lks5uq10vgaJpZM4YFdj0.

[boygirl]

Whoa! That's rad!

[bingomanatee]

So its a rough but I am pretty sure it works in principle with a lot less code debt.

So if you like this approach, feel free to formalize this, or we can put Freactal with Dojo and Ember and all the other also rans.

On Nov 2, 2018, at 1:59 PM, Lauren notifications@github.com wrote:

Whoa! That's rad!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormidableLabs/freactal/issues/112#issuecomment-435503140, or mute the thread https://github.com/notifications/unsubscribe-auth/AApv8CVLCXROjA066RudQJN0FQ-12z6aks5urLJPgaJpZM4YFdj0.

[bingomanatee]

I’ve validated the basic premise - it works.

https://www.npmjs.com/package/freactal-rebuild https://www.npmjs.com/package/freactal-rebuild

How are we with this?

On Nov 2, 2018, at 3:41 PM, Dave Edelhart dave@wonderlandlabs.com wrote:

So its a rough but I am pretty sure it works in principle with a lot less code debt.

So if you like this approach, feel free to formalize this, or we can put Freactal with Dojo and Ember and all the other also rans.

On Nov 2, 2018, at 1:59 PM, Lauren <notifications@github.com mailto:notifications@github.com> wrote:

Whoa! That's rad!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormidableLabs/freactal/issues/112#issuecomment-435503140, or mute the thread https://github.com/notifications/unsubscribe-auth/AApv8CVLCXROjA066RudQJN0FQ-12z6aks5urLJPgaJpZM4YFdj0.

[boygirl]

@bingomanatee I'm soliciting some code review from some of my colleagues, but I love the idea of simplifying where we can.

[bingomanatee]

FWIW I am vacillating between using the injectors’ store and an xstream based store. The former gives a more familiar basis/behavior, the latter gives deterministic synchronized changes.

On Nov 5, 2018, at 9:46 AM, Lauren notifications@github.com wrote:

@bingomanatee https://github.com/bingomanatee I'm soliciting some code review from some of my colleagues, but I love the idea of simplifying where we can.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormidableLabs/freactal/issues/112#issuecomment-435967945, or mute the thread https://github.com/notifications/unsubscribe-auth/AApv8L3j8Qibff78xaq1N1po9x0drQkIks5usHmLgaJpZM4YFdj0.

[boygirl]

@bingomanatee I haven't been able to wrangle anyone with the appropriate context (ha!) to give a thorough code review of this re-write. Maybe @divmain or @julien-f would be willing to step in.

Either way, I'd like to set you up with all the permissions you need to officially maintain this project. Can you tell me your npm user name?

[bingomanatee]

Alright. For the record just now realized this was a public conversation.

I'd like to get some feedback from the community. Would people prefer

1) That I continue to incrementally improve the current codebase and add improveuments to it, keeping the API consistent or

2) That I radically change the codebase, bringing more information into change scope.

One of the big changes I want to do is to adopt the modern context defintion, which will of course bind Freactal to the 13.x branch of React. This does not mean it WON'T work with other platforms -- the wrapping/retrieval of context will be internal to Freactal.

https://www.npmjs.com/package/freactal-rebuild

is my POC of how something like that will work.

This is irrespective of the choices mentioned above.

[bingomanatee]

There are a few big changes I want to do in the API system:

1) expose state and effects inside freactal effects (actions). 2) allow "NOOP effects" (calls) that call sub-effects but are not themselves responsible for directly changing state 3) make it easier to write update-style effects (actions) - perhaps splitting the effects collections into three groups, "actions", "mutators", and "calls".

• actions return objects that behave like setState in react, asserting their properties over the object. (partial update
• mutators return a new state object that completely replaces the current state.
• calls return nothing as other effects are inside them internally, they call those and indirectly change state. 4) import some of the techniques/approach from freactal seed, making it easier to write initializers and effects in one stroke, and potentially to bring in some sanitization of data 5) synchronize Freactal states with other systems as a built-in feature. This includes local storage, but opens the opportunity to build streaming stores that sync with remote data, REST, sockets, etc. 6) add reducer hooks both to the injection and the provision . This allows you to more carefully blend parent effects and children effects as well as to write computed state at the injector level. This will allow for computed state to bridge multiple states potentially as it will have access to the net store state. Reducers could take in only a subset of state and inject it into a sub-freactal state, allowing for redux style partial trees. This also means that you have more freedom about deciding how to express freactal state into child views; for instance you could write a reducer that writes state state directly to props, or that writes a "freactal" property to props with state and effects, etc. 7) Expose the core store as a class so that you can write your own adaptive layer between a store and a view for any framework you choose 8) expose a "state" context, so that for views that want read-only access to store from their parents you can exploit the context directly and listen to store changes. 9) adopt xStream under the hood as a reactive state engine to make it easier to react to state change, observe micro-events, etc.

Obviously this is more than just maintenance; probably this more resembles the "Angular 2 breach". A big stamp for "Freactal 1x" would have to be made. But given current adoption rate, what do we have to lose?

thoughts?

[boygirl]

@bingomanatee at this point I would like to consider you the official maintainer for this project, so how you want to go about this will be mostly up to you. You're welcome to announce/document your involvement however you like. Since we're still hosting it on our org, we want to make sure the quality of the project and associated documentation stays high, but the implementation will be totally up to you. I do ask that if you transition the project to your Context rewrite that you're careful to document any user-facing deviations from the original and publish some kind of migration guide for folks if necessary.

I also spoke with @julien-f and while he isn't interested in maintaining the project, he is willing to help out here and there.

Thanks so much for stepping up! I'm going to close this issue now, but feel free to email me directly at lauren.eastridge@formidable.com