reduct/discussions

Discussions regarding the organization.

discussions's Issues

Reduct Logo

We should decide and create logos for the reduct organization - I've been playing with this lately:

@akoenig @grebaldi

Package names

Regarding the existing packages @akoenig and myself had a discussion today.

We both came to the conclusion that all packages should have a short and rememberable name, so the ComponentDomParser for example definitely needs a rebrand. @akoenig proposed assembler which I really dig(Even though it has a connection with the language itself)! So thumbs up for that!

Regarding the NodeProto - I am unsure about that one at the moment, I think if we scope the packages under the organization name f.e. @reduct/assembler we could just name it component.

What are your thoughts about that @grebaldi @akoenig ?

Small DOM abstraction library

We should provide a small, lean DOM abstraction library which avoids dealing with some quirks like NodeList to Array conversion, event handler registration/deregistration and so on.

Traversing

import domy from 'domy';

let elements = domy.query('.foo');

Event handling

import domy from 'domy';

let click = domy.register('click', el, handler);

domy.release(click);

Thoughts @grebaldi @Inkdpixels?

@reduct/* dependency levels

This causes me some bit of a headache... The more we generalize, the more we get into trouble with our attempt to reduce our dependencies down to zero.

I therefore suggest, that we define a rule that defines "low level" libraries from our side, that are allowed as a dependency inside of the others. We already talked about a Utility Class living besides Assembler - I now need the very same functionality for Registry...

I'm open for other solutions to this, but I think we need to address it soon to stay DRY.

Master Index

I had a few talks with @Inkdpixels today about dependency injection and stuff. There is a loose idea of having an index of classes, that can be accessed by a yet-to-write(tm) DI library and that also could be shared with componentdomparser.

In a framework context it would be easy to add a build step, that automatically generates that index, so there's no hassle to maintain it.

I could take my shared scope library and transform it into something that could fulfill our needs regarding that with the benefit of it offering access to application dependencies accross different application contexts.

Here's the link: https://github.com/PackageFactory/pflibs--shared-scope

@Inkdpixels @akoenig What do you think?

EDIT:
btw: let's call it @reduct/matrix -> no naming discussion there, huh? :P

Standards

We should have standards across all packages on which we agree.
For example coding guidelines, folder structure, the structure and style of the README.md, a code styleguide for JSCS/ESLint or the like, and we should agree on a test suite as well(At least for the moment).

Coding guidelines:
We should work that out together in a direct discussion I think. (Maybe next week?)

Folder structure:
Use the structure from NodeProto as a starting point? Any other suggestions/Feedback on that structure?

Structure of the README.md
Same as above?

JSCS/ESLint:
What tools do we want to use? Both? I think that should be the case. We should then map out our ruleset in a direct discussion(The same as the coding guidelines).

Test suite:
Karma, Jasmine, QUnit, Jest?

We should also create a separate repository with these guidelines and embed them as a submodule/npm package(?).

@grebaldi @akoenig

New Package: Validators

As discussed in reduct/component#15 - We should separate the propType validators from the Component. Any name suggestions here?

Maybe reduct/validity?

@grebaldi @akoenig

Move to Commitizen for commit guidelines

We should discuss using commitizen as our commit tool of choice. This would play against our decision on staying with the commit guidelines of the Neos/TYPO3-Core, but maybe there is a way to configure commitizen.

Documentation via JSDoc

As @grebaldi suggested; We should use JSDoc or another tool for documenting our code.

reduct/component#31

Standardized commit message prefixes

Should we use the TYPO3 guidelines for this?

Add a code of conduct to our repositories

As suggested in:

http://contributor-covenant.org/version/1/2/0/

And suggested by:

https://robots.thoughtbot.com/adding-a-code-of-conduct-to-open-source-projects

What do you think?

BigPicture

Sooo... Do we agree on the need of a big picture beforehand?

For me, this organization definitely should aim at being a "framework", but not a typical framework where everything is bundled into one big monolith. We should prioritize that each package should be abstracted and could be used individually, and still harmonizes with the other packages(Duh! This could be hard, but it's possible - And why go the easy way if you can lay bricks in front of you!).

I told @grebaldi today that we definitely need Example Components, but also examples for applications like the typical ToDo-App or a Code-Editor or the like. These examples could be used to pinpoint our goals - small packages, which play nicely hand in hand and creating a solid foundation.

@akoenig @grebaldi