Fork me on GitHub
#fulcro
<
2017-12-05
>
tony.kay02:12:27

@wilkerlucio Got a regression on add-basis-time

tony.kay02:12:43

not working right on unions it seems

wilkerlucio09:12:48

@tony.kay +1 for removing children on defsc

wilkerlucio09:12:55

I'm going to look into the broken example you sent me

roklenarcic09:12:17

@tony.kay -> chrome complains about https certs

thheller09:12:57

has anyone confirmed that react v16 doesn’t break the bindings the component render does?

wilkerlucio11:12:21

@thheller didn't had a chance to try, but my guess is that it would only break with the new async rendering (that comes disabled by default as far as I know), are you trying it? I'm also curious about how that goes

thheller11:12:37

I’m probably not going to use fulcro as I really dislike the protocols and “macro infection” style from om.next

thheller11:12:48

so I didn’t get that far in my tests but some tests I did in the past didn’t work too well with binding

claudiu12:12:16

@thheller what are you going to use instead ? protocols & macros aside, fronend & backend complete story + normalized db + a lot of complexity that just isn't there. Could not find anything close to fulcro for my projects.

wilkerlucio12:12:46

I can relate to pain with macros and protocols, but I think Om.next/Fulcro does a good usage of then, it enables the components to know a lot about themselves without having to spread logic across the entire project, I don't bother at all with then (although I was reluctant to start using macros like defsc, in the end I accepted they are better than the other option), and like @claudiu said, I can't find anything that gets even close to the complete story that removes so much complexity out of my code

thheller12:12:36

I should clarify: I’m probably still going to use parts of fulcro. I pretty much like everything except the react interop

thheller12:12:11

so I’m looking into decoupling that so I can still use the other stuff

thheller12:12:56

defsc looks better but has too much magic (and still uses defui under the hood)

tony.kay16:12:47

@thheller I’m moving towards a form of defsc that makes the magic optional (and am liking it better). I need to keep defui around in order to make porting from Om next easy, since there are a lot of people that use Fulcro, and many that end up coming in from Om next with existing code.

tony.kay16:12:29

In fact, the new defsc is done, and I’ve just been updating the documentation…a very time-consuming task because there is so much 😉

tony.kay16:12:44

I’d be interested in hearing any proposals on how the react interop could be better.

tony.kay16:12:19

@roklenarcic because it doesn’t have any SSL certs 😉

tony.kay16:12:09

React 16 worked last time I tried it. Why would it break binding?

thheller21:12:01

@tony.kay I’m just super picky about macros and the code they generate so really don’t listen to me.

thheller21:12:27

I had hoped it would be easier to just pick the parts I wanted but I guess thats not the goal of fulcro at all

tony.kay21:12:31

Yeah, the react generation isn’t just react…it is critical to the entire model for simplification

tony.kay21:12:15

data model + top-level transactions as data + UI refresh via reasoning about data + server interaction via that same data

tony.kay21:12:23

it’s very much tied together

tony.kay21:12:04

The server stuff is easy to swap out however you want, but the client has a very intentional design where all the parts fit together

thheller21:12:27

yeah that is probably a good thing. I’m just not ready to let go of the stuff I already do in my own apps.

thheller21:12:08

still messing around with a few things … I still like fulcro a lot

thheller21:12:26

I was looking for ways for fulcro to let me know when certain idents/keys change

thheller21:12:00

but its all pretty tightly integrated

tony.kay21:12:14

but that thinking is inverted….fulcro doesn’t change any data: you do.

tony.kay21:12:29

there are no event systems in it other than for hooking up to browser controls

tony.kay21:12:51

what do you want to do when “certain idents/keys change”?

thheller21:12:35

I guess I want a custom reconciler/indexer

tony.kay21:12:43

right…but why?

tony.kay21:12:29

in other words, what need do you have? Perhaps you’re missing something grander by holding onto something old

tony.kay21:12:43

perhaps I’m insane and have crap 🙂 I’m always interested in exploring that question 😜

thheller21:12:25

why is reconciler passed down through props? why do you not use context?

thheller21:12:36

(I don’t trust bindings)

tony.kay21:12:09

ah…implementation detail. Not tied to it at all. Inherited it from Om Next. Would be happy to change it, though I don’t want globals (more than one app on a page)

tony.kay21:12:48

(before 2.0, I had no control over it…so I’ve not been able to even question it until now)

thheller21:12:08

its pretty much all implementation details 😛

tony.kay21:12:35

Given what you maintain, you now have me afraid of binding…what’s the issue?

thheller21:12:07

the problem with binding is everything async

thheller21:12:39

and there is a scary new amount of async in the react v16 fiber stuff

thheller21:12:13

it is probably fine where it is used right now

tony.kay21:12:29

ok, that’s fair. Off the top of my head, I think we’re safe there, but I do agree that async (or even webworkers) could have impacts.

tony.kay21:12:00

they are only used during the react element generators, which should be pure functions that contain no async ever.

tony.kay21:12:46

all of the bindings are also intended to be private, so UI should not be able to derive values from them that could screw up later (say on a lifecycle thing)

tony.kay21:12:29

things like the reconciler are singletons, so even if you did close over it, it would not hurt anything. All of the internal things that change are in atoms, so you would never be “stale”

tony.kay21:12:26

So, you’re indicating a preference for using Javascript’s “this” context stuff?

thheller21:12:55

react context

tony.kay21:12:08

ah, whew….

thheller21:12:22

although that never was official either. it has worked well for me 😉

tony.kay21:12:04

Yeah, they have this to say in the docs “If you want your application to be stable, don’t use context. It is an experimental API and it is likely to break in future releases of React. ”

tony.kay21:12:13

not getting fuzzies for a library

thheller21:12:12

hehe yeah its a bit of a pain to work with too

thheller21:12:49

but its essentially just passing down one variable (eg. the reconciler) automatically without having to pass it to props every time

tony.kay21:12:45

well, good to know it is there. If it causes any problems I’ll at least be aware of the alternative.

tony.kay21:12:45

none of the stuff in binding is intended for end-users

tony.kay21:12:53

BTW, thanks for looking at the internals…more eyes = fewer bugs 🙂

tony.kay21:12:47

some of it is still kind of a mess (the application startup is a hair ball, and the server stuff evolved in too ad-hoc a manner)

thheller21:12:55

I looked at om.next a while ago and you fixed some of the issues I had with it

tony.kay21:12:09

easy server is great for getting started quick, but not really idea overall for production. The newer modular server stuff is probably overkill. It was intended to make full-stack libraries easier to build because they’d have a target on the server. I’m still analyzing if that makes sense. I’ve been leaning towards beefing up the docs around “building your own server” with handle-api-request, and documenting easy server as an early dev tool.

thheller21:12:10

but also inherited some others that are still there 😉

tony.kay21:12:46

well, I’m working on this like 12 hours a day. Point them out 🙂 if they aren’t part of the core user-visible story, I’m game.

thheller21:12:02

I will … still exploring. It just my :advanced problem radar going off too early probably

tony.kay22:12:20

There is one very big thing I think is a real crappy thing (got from Om next): https://github.com/fulcrologic/fulcro/issues/67

tony.kay22:12:47

that one sets on warning bells every time I see it. Definitely going to fix that gem soon

thheller22:12:46

not sure I understand the problem

tony.kay22:12:46

did your head just go CLANG CLANG CLANG?

thheller22:12:39

yeah thats ugly but why does that break anything?

tony.kay22:12:44

The problem is the static protocol implementations. If you make them, but never call them via the class, then advanced optimization removes them.

tony.kay22:12:00

1. If the compiler changes the implementation of protocols…renames methods,e tc.

tony.kay22:12:22

2. If your dev environment refreshes namespaces (via tools-ns), it can “undo” the hack

tony.kay22:12:33

we actually got bit by this for months

thheller22:12:04

ah so the issue is that closure is not smart enough to figure out the fns are actually called

thheller22:12:36

easy answer is to use goog.object/set

tony.kay22:12:09

See….more eyes 😉

tony.kay22:12:14

hm…it’s all mixed up with specify! though

thheller22:12:15

its a bit harder since you want to have an actual protocol

tony.kay22:12:59

quick-n-dirty is to emit a try/catch with static calls to them (top-level code that just silently runs in namespace)

tony.kay22:12:37

makes code size bigger, but I like that better than the compiler hack. better fix is to figure out how to emit code that doesn’t get optimized away

tony.kay22:12:05

https://developers.google.com/closure/compiler/docs/limitations this page explains what is wrong (under flattening, and statics)

tony.kay22:12:11

to support SSR and other things, we never call query or initial-state on the class…we use helpers that turn it into a variable. Boom.

tony.kay22:12:45

I’m also game to move away from the protocols. I mean, defsc is already a move in that direction. It makes it so people are no longer writing protocols. At some point it would be possible to make it so that protocols are not actually involved at all.

tony.kay22:12:42

in practice we’re using static protocols for everything important, and when mixed with SSR you need a helper wrapper anyway, and never end up even directly using the protocol. So, in practice, it’s kinda silly

tony.kay22:12:48

that said, that kind of transition needs to be made a bit more slowly. I have users that would not like things breaking in big ways with their source code. Trying to keep it all scriptable for 2.0…just some renames.

tony.kay22:12:22

But something new that we can transition towards is totally doable in the near future.

thheller22:12:22

I’ll try to finish the “fulcro-light” defui replacement I started. when it works that might be an option

thheller22:12:59

good excuse to go over some impl details anyways

tony.kay22:12:20

sure…be glad to chat with you on anything you have questions about.