thoughts

[mattdesl]

I'm digging this. 👍 My two cents:

I was initially pretty confused reading through source, until I realized it was the transpiled output. Maybe it would be better to only transpile on prepublish, and avoid bloating github with transpiled code. Or, putting it in a build or dist folder.

It would also be great to embrace other modules a bit more rather than try to reinvent the wheel. Some inspiration:

• xhr
• insert
• add-event-listener
• dom-css or prefix-style for applying styles
• is-dom
• and more

[hemanth]

+1 For revamping the publishing process (also felt the same), feel free to send a PR on module-template this is what is being used for all the modules that are created here.

Yup npm-dom is cool, the idea is keep everything as functional as possible.

fp-js would be all the helper/util js for fp-dom is the idea.

Thank you for pitching in :)

[stoeffel]

👍

[hemanth]

@mattdesl Still interested?

[stoeffel]

I have put some thoughts in it and I would prefer to change some stuff in the current implementation, to embrace a truly functional api.

1. I think I would deprecate fp-js in favor of ramda (and ramda-fantasy). Ramda is much more sophisticated (and why inventing the wheel twice)
2. Removing side-effects by returning monadic data types (i.e. IO, Maybe or Future from ramda-fantasy

f.e.

- const blueLi = addClass(always('blue'), select('li'));

+ const blueLiIO = R.compose(R.map(addClass('blue')), select('li'));
+ blueLiIO.runIO();

1. using transcribe to create an api doc from a Hindley–Milner type annotation.

// select :: String -> IO(Maybe(DomElement));
const select = function() { /** ... **/ };

[stoeffel]

The current API has only one feature (currying). With adding monads we would gain a lot more, and that is a side-effect free API for the DOM.

[stoeffel]

Maybe we should also consider moving to a mono repo. It's much simpler to maintain/document and understand by new users.

[stoeffel]

It would also be great to embrace other modules a bit more rather than try to reinvent the wheel.

@mattdesl Totally agreed. IMO this should become a side-effect free, curried functional-api to the DOM using other modules or our own implementations.

[hemanth]

I think I would deprecate fp-js in favor of ramda (and ramda-fantasy). Ramda is much more sophisticated (and why inventing the wheel twice)

@stoeffel Agree.

[stoeffel]

cool.
What do you think about the other ideas I proposed?

[hemanth]

@stoeffel :

monadic data types

and

Hindley–Milner type annotation

Will be good to have, but would need a introduction as most of them from JS world would be new to it.

I am not really a big fan of a mono repo...

[stoeffel]

Yop, it would need a intro or some links. I can live without a mono repo. But I think it would make it a lot easier for new users to get started. We could still publish individual modules.
We could use https://github.com/kittens/lerna

[stoeffel]

select returning an IO

const selectorAll = function(query) {
  return new IO(function() {
    return document.querySelectorAll(query) || [];
  });
}

const innerHTML = R.lensProp('innerHTML');

const headInnerHtml = R.compose(
  R.view(innerHTML)
, R.head
)
const lines = R.split('\n')

const text = R.compose(
  R.map(
    R.compose( R.toUpper
             , R.head
             , lines
             , headInnerHtml
             )
  )
  , selectorAll
);

console.log(text('h1').runIO());

[hemanth]

Looks much better! Thanks.

@stoeffel Let us create a todo list and attack this!

[stoeffel]

Sure, let's do this. Would be cool to hear what @guumaster or @mattdesl thinks about this changes.