Thoughts on v2

[emyann]

Planning a v2.0.0 for Morphism with those changes:

• [ ] Tag Morphism Registry as deprecated (not so used?). Will be removed in v3.

• [x] Runtime checks as https://github.com/gcanti/io-ts https://github.com/nobrainr/morphism/issues/84

• [ ] Typescript support for nested paths https://github.com/bsalex/typed-path (https://github.com/nobrainr/morphism/pull/53)

• [ ] Remove string dot notation access and replace with an array, better support for TypeScript

  • Need to remove ActionAggregator from schema support

• [ ] Provide a post processing step to remove some specfic keys (like checking for null values). https://github.com/nobrainr/morphism/issues/85

• [ ] DataViz for Schemas, per https://github.com/nobrainr/morphism/issues/47#issuecomment-495947688

• [ ] IE Support: https://github.com/nobrainr/morphism/issues/130

Please share any ideas or suggestions you would find valuable for a next version :)

[davej]

Awesome, this is a really nice lib.

Probably way outside the scope of what this library is for but it would be cool to be able to output the schema transformations on some sort of diagram. Perhaps an online tool or CLI that outputs to something like d3.js.

[emyann]

@davej This is definitely something I had thought about! I really love the idea, I just didn't know if this could be valuable. Thank you a lot for bringing this on the table, I'll add it to the list :)

[reitsma]

This looks really nice. I am using the JOLT java library in the backend. For the frontend transformations I consider Morphism. I have one specific requirement: The transformation schema must be expressed in JSON. As far as I understand, that can be done with Morphism, my own code will do the (trivial) parse of the JSON before handing the scheme to Morphism.

[emyann]

@reitsma Thank you for considering using Morphism! I don't see any actual blocker for your use case ? If you're able to parse and revive the functions you might have in your schema, it's going to work straight away.

[cjancsar]

Might be nice to have easy hooks to sanitize data during mapping. Can currently do this manually with a function mapper, but might be nice to have a more abstract way.

We are not using typescript at the moment unfortunately.

Think of an integration with sanitizers like validator.js, like express-validator does.

We are using this lib to connect backend services with our internal micro-services, as an ETL-like process. This library is great to map the data, but needs a bit more in the transformation-side.

We are just starting to use it, and I would be happy to help out in the coming months.

[emyann]

@cjancsar This is awesome that you bring this on the table as I'm actually working on the Validation side of Morphism! This is only available on the next branch of this library (npm install morphism@next).

This is not yet ready for production but you can see a sneak peek here:

• https://repl.it/@yrnd1/Morphism-Simple-Validation
• https://repl.it/@yrnd1/Morphism-Validation-Custom-Reporter
• https://repl.it/@yrnd1/Morphism-Validation-Custom-Reporter-And-Formatter

I added some basic string validators here https://github.com/nobrainr/morphism/blob/next/src/validation/validators/StringValidator.ts like min, max, length, alphanum, regex and planning to add more in the future.

Is it similar to what you had in mind ?

[cjancsar]

@emyann yes! That is exactly what I was thinking.

Do the validators have the ability to change the data, or are they read-only, and only throw errors?

Are you re-creating all your own validators? I know you likely don't want to add an external dependency, but the lib might also get more recognition and wide-spread use if it connected to the already-awesome validator.js which has tons of existing validators.

It also has sanitizers, which coerce the incoming value to another format / clean the data. Would also be nice to see that.

For example:

import { morphism, createSchema, Validation, Sanitization, reporter } from 'morphism';

const source = { name: 'Cassandra', id: '14' };
const schema = createSchema({ 
	id: { 
		fn: (source:any) => source.id, 
		validation: Validation.isInt(),
                sanitization: Sanitization.toInt()
	} 
});

> output = { name: 'Cassandra', id: 14 }

Pretty basic example, but you get the point.

[emyann]

Awesome!

Do the validators have the ability to change the data, or are they read-only, and only throw errors?

Yes actually it does coerce the value to another format and I wanted to give the user the ability to choose the behavior, but I really love the suggestions you shared (Sanitization, integration with validator.js). I'll work on making the validation interface more composable so that it would be easy to plug any other validation / sanitization library rather than taking a dependency on a specific library (if some prefer joi over validator.js it would be possible)

[cjancsar]

@emyann cool! Let me know if there are any low-hanging requirements and I will try and spend some time helping you out.

[emyann]

@cjancsar Yes of course, thank you for offering your help! I'll wrap my head around the integration with 3rd party libraries and prepare the ground for the work. I'll get back to you whenever I start this refactoring.