Fork me on GitHub
#fulcro
<
2017-11-26
>
cjmurphy05:11:11

In Fulcro 2.0 is the suggestion to have the define as [fulcro.client.primitives :as prim] rather than [fulcro.client.primitives :as om]?

tony.kay07:11:14

that’s what I’m doing…om seems a misnomer (doesn’t match the ns anymore and would confuse new users)

wilkerlucio11:11:36

@tony.kay just curious, why the primitives name? any reason to prefer it instead the conventional core?

tony.kay16:11:38

Several reasons: 1. I’m hoping to be able to use git to roll Om Next history for that file (and dom) into mine. This will also let me follow bug fixes more easily). It also gives contributors there better credit. 2. The functions in next.cljc are at the edge of the dependency graph. The ones at core are not. Trying to move them into core puts them higher up, and would force me to make more API renaming changes in order to resolve circular dependencies (core refers to networking, which refers to primitives…if primitives moved into core: core would refer to networking would refer to core. This is true of a number of the namespaces…it becomes a real spider’s web) 3. Large files take a long time to compile. The more I jam into a single file, the worse incremental update compile times I get when working on the library

tony.kay16:11:17

If anything I’d love to bust the thing up and move code that isn’t needed as public API to another file to improve the (incremental) compile time. @wilkerlucio

tony.kay16:11:49

4. The name next.cljc is a misnomer for Fulcro…the functions there are the low-level API that Fulcro builds upon. primitives seems a good choice. I’d be open to suggestions. That one is the best I could come up with given the nature of them + a thesaurus

tony.kay16:11:33

I was tempted to split them…put defui and some other really common ones into core…but that makes porting a heck of a lot more work, and the circular problem comes up depending on the function/macro

tony.kay16:11:05

if anything, I’m much more tempted to rename core 😜 I don’t care for that name in practice. It gets overused. People use it in different namespaces in the same project (leading to nav nightmares), etc. If I didn’t think people would be just as silly with an alternative I’d have the compiler reject it as a name.

tony.kay16:11:13

Moving InitialAppState into primitives also makes sense to me. I don’t know…anyone care to riff on what should be where? Once 2.0 ships I won’t want to do renames at all. I don’t like renames, but since we’re already forced to do some…

tony.kay16:11:39

I’ll open an issue

tony.kay16:11:31

If I were doing this without existing users, there would be a lot of things I’d rename/move 🙂

tony.kay16:11:59

well, that’s not necessarily true. I’d split primitives into parts. I’d clean up some legacy names. I have already done a bit of that in terms of implementation functions that were never part of the public API.

johnny16:11:43

As a completely new user of Fulcro with existing knowledge of om next should I pick fulcro 1.2 or go directly to the 2.0 alpha?

tony.kay16:11:46

either one at this point. 1.2 is stable, and 2.0 might have bugs still…but those should resolve quickly. The main thing is you’ll want to build the dev guide for 2.0 yourself instead of using the online one (same with other docs…the 2.0 branch)

tony.kay16:11:10

2.0 will ship more formally with doc publishing in a few days

tony.kay16:11:44

the port is trivial, and can be done with a shell script...

tony.kay16:11:07

so, it really doesn’t matter unless there’s a feature of 2.0 you can’t live without 😉

johnny16:11:38

I don't think so 🙂, my main concern was whether the port was less than trivial wich it is in most cases when you do a +1 version bump. Good that it isn't though, thanks!

tony.kay17:11:29

yeah, the reason for the major bump is dropping the direct dep on Om Next and instead pulling in the relevant code to our code base. Many reasons for this, explained elsewhere (see README 2.0 on 2.0 branch). That results in the need to rename things in your code, but I’m doing my best to maintain API compatibility where we’re not “fixing” something (e.g. dynamic queries are different in 2.0)

tony.kay17:11:05

so, 1.2 stuff will not run unchanged…but I’m trying to keep the changes easily scriptable