Administrative discussions w/ the Flower Platform team

[lilfolr]

Discussions with the Flower team & their fork.

From #183

[cristian-spiescu]

Hi there!

I noticed that while working at the project, we have the need to make some commits that are not fully fledged features. But rather small improvements, refactor, etc. When we work on our own projects, we usually mix such commits w/ work done for features. Here, we tried to separate them, in order to avoid pollution of a bigger commit that focuses on a feature. Because this will make your life harder when reviewing the "big" commit for a feature.

Such commits are #257 or #260. I observed that they are both about 2 month old, and I did send an intermediate reminder. I know that motivation to integrate such commits is not great. Maybe if we'd talk about a feature: you'd book some time. But if the commits don't do much (practically) => motivation to integrate tends to 0.

But how should we proceed w/ such commits? Because I observe that they do happen.

Or maybe the current dev flow that we have, for which we target full sync is not doable, because it requires some time from you. A solution would be to stop having such process. And let our fork have its separate like. And if needed, you may pull features from our repo.

What's your opinion on these matters?

[lilfolr]

I am happy to take minor PRs, but equally happy for you to mention new features you've added here, and I can pull them in.
It does, unfortunately, take some time for me to get to look at PRs and issues, but I dont think this should block you.

I am looking at modernizing this repo. Many of the core dependencies are a few major versions behind, and I believe the maintainability of the repo, and performance of the library would benefit from some refactoring.
I aim to keep things as backward compatible as possible; but I am aware that this will impact forks. If you have concerns/suggestions let me know. My plan (in order) at the moment is:

1. Move to Typescript
2. Upgrade to modern react (18)
3. Move the code base to modern react features (functional components with hooks)

[cristian-spiescu]

Regarding point 3. I don't understand why people (specially libraries) tend to switch towards functional components. For a library, working w/ classes, gives people the opportunity to extend the component class if needed. OOP has the great advantage of reusability via inheritance.

From a "user" perspective (i.e. app developer, not lib developer), it's understandable. It's less code to write. Although, personally I see disadvantages here as well. E.g. the state is "scattered" within the functional component. When you read a component, it's not clear upfront what's the component's state.

So in my opinion, it would be better to stick to the class components.