Bugfix/fix input example #256
Conversation
| Helper function to narrow down a list of all possible style props to | ||
| one specific to a type of component | ||
| */ | ||
| let rec extractViewStyles = (styles: list(allProps)): list(viewStyleProps) => |
There was a problem hiding this comment.
I would like to generalise this but can't figure out how, its that or create one whenever we need a utility to separate a certain subset of styles from another. Say you create a custom component comprised of text and view components so it will take a style list of coreStyleProps + extra fontProps but then as the view is not allowed to have fontProps they need to be split out in the implementation part of the custom component.
Its very possible this isn't something we might need a lot 🤷♂️
There was a problem hiding this comment.
Good question, I'm not sure this would work either 🤔
| @@ -166,6 +166,17 @@ let make = | |||
| style, | |||
| ); | |||
|
|
|||
| let inputFontSize = | |||
There was a problem hiding this comment.
Also tried generalising this as it seems like a much more common use case to get the specific value of an item in the style list if you want to do some internal logic based on it.
I tried something along the lines of the above but
/* Inside a fold_left */
switch(valueIWant, variantType) {
| ("marginTop", MarginTop(mt)) => mt
/* ....etc */
}the compiler doesn't seem to be able to narrow down the return type this way, could have been a question type annotating it properly but I couldn't work out how
There was a problem hiding this comment.
Maybe for some of these - it'd be worth just calling Style.applyStyle, getting a record, and asking that for the value?
Like:
let { height, fontSize, color } = Style.apply(style);
There was a problem hiding this comment.
this issue with that approach is that since style.t is strictly typed and records in general are strictly typed I can't return a record that maps to exactly what was passed in if I return a type t then I'm forced to set some default values which aren't all undefined which can muddy the waters in terms of know what was actually in the style list and just that, a potential alternative might be returning another data type like a map or a tuple, ill experiment in a separate PR
akinsho
force-pushed
the
bugfix/fix-input
branch
from
926012a to
7fc36d0
Compare
This fixes the input component example which #205 broke, it involves having to pull values out of the style list which I wanted to create a sort of getter for but having done a bit of reading and wrangling with the compiler doesn't seem straight forward, typing gets a little tricky with variants will keep it in mind and revisit once I've leveled up my reason/ocaml know-how (tracked by #239)