-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Still maintained? #186
Comments
By the way, it may be the case that the library is "finished" in that there are no more changes to be made and it fully captures the intended scope for some version of React. In which case, I'd still be interested in expanding out the documentation provided someone can help me get through the problem-areas I've encountered. |
Hey @benbellick We polished jsoo-react as the minimum to be able to study the possibility to use jsoo at ahrefs. After a lot of debate we settle down with Melange and put all of our resources there. The pain points of jsoo were mostly about integration with JS ecosystem, the boxed primitive types, the lack of community and the familiarity from our frontend team, to name a few. That being said, there's a bunch of work put into jsoo-react that makes it possible to use and extend, but it's far from finished, if you feel encouraged to pick some issues I'm happy to guide you. Besides this, I would like to recommend Melange :) since we are making sure it's getting very good support from dune and seamless usage within OCaml codebases. |
@davesnx I see, that makes a lot of sense. Thanks for the response! The way I view the melange vs. jsoo comparison is about whether or not your preference is nice interplay with existing OCaml code vs. existing JS code. In my use case, I wanted to work with an existing OCaml codebase, which is why I wanted to try and make this library work. One pain point I encountered (which I believe also exists in As a really out of context example, I have a codebase where I wanted to read in a string from an input here: (* Some file *)
input
[|
type_ "number";
value (string_of_int divisor_count);
onChange (fun e ->
e |> React.Event.Form.target |> Getters.value
|> int_of_string_opt
|> (* more processing... *)
|]
[];
(* in getters.mli file*)
val value : Ojs.t -> string [@@js.get]
Point of emphasis is the use of the Is there a reason why we can't just have a function which takes in the value produced by |
First, just want to say this library looks pretty awesome and I've been having a lot of fun getting my hands dirty, thanks for all of this work!
I have encountered some difficulty, specifically with getting values out of events. I found one solution that seems to work here, but it involves defining a function which makes an external call to identity, i.e. its doing some magic type-cast.
Additionally, I wanted to be able to read the values submitted within a form tag, but found that was also super tricky,
e.g.
Any ideas on how to fix this?
In addition, I am wondering if this library is still being maintained, as I see there haven't been any commits in a while, and it seems people have gravitated more towards Reason-React. My interest in this repo stems from the fact that I can use an existing OCaml repo without modification.
So, my question: is the library still being maintained, and if not, is there a reason besides lack of interest, or is there a technical reason why this wasn't the right way to solve the problem? If it is the former, I would love to be part of an effort to bring it back up to speed :)
The text was updated successfully, but these errors were encountered: