These are chat archives for mithriljs/mithril.js

23rd
Jul 2019
Dominic Gannaway
@trueadm
Jul 23 2019 00:01 UTC
thank you! :)
Barney Carroll
@barneycarroll
Jul 23 2019 00:01 UTC
I think there's something here which hacks at a vicious cycle in 'bidi' flow
Your notions on removing dynamic qualities from signal expressions are good inasmuch as they can ie curtail the strange rituals that 'stores' etc have to go through to demistify events
Dominic Gannaway
@trueadm
Jul 23 2019 00:04 UTC
I just realized, that everyone is so focused on passing callbacks, which is how the DOM works today, that they never stopped to think if they could have a "virtual events" abstraction that uses something like signals to pass "up" data through the tree in a declarative nature that is composable. I had these ideas years ago when I wrote Inferno tbh. I was so scared to share them because of imposter syndrome, that I just stuck with the norm - let's be like React or "close to the metal" i.e. do the DOM way.
Fred Daoud
@foxdonut
Jul 23 2019 00:05 UTC
Do it the "Dom" way instead of the "DOM" way.
ha ha ha ha ;)
Dominic Gannaway
@trueadm
Jul 23 2019 00:05 UTC
Then I had a rough patch at FB, and thought fuck it. I'm going to persuse my ideas and challenge everything and then I made it all work with the new FB website and people were like "holy shit, you're on to something"
Haha :)
When you work with such talented visionaries at FB and they even pause and there's no response, you know you've done something right.
The big issue here is though, and this is why this is not public right now: I don't know if people will like this.
It's a big departure from what the DOM and browsers provide right now. Many folks at Google etc are trying to promote "use the platform" and this is basically the complete opposite.
It's still food for thought regardless.
Barney Carroll
@barneycarroll
Jul 23 2019 00:11 UTC
@trueadm this is it right? until now, broadly speaking, 'virtual dom' has signified an ability to abstract the imperative DOM API into something more expressive. But at this point you're looking to abandon the fundamental underlying analogies for more rationable models of signaling?
Dominic Gannaway
@trueadm
Jul 23 2019 00:12 UTC
I'm just trying to rethink events. They're so important, and people just think they're callbacks that do something X and then reduce state and do Y.
It's all imperative tangled crap that is so hard to test that we end up with writing tests that are:
Barney Carroll
@barneycarroll
Jul 23 2019 00:12 UTC
LOL
Dominic Gannaway
@trueadm
Jul 23 2019 00:12 UTC
getComponent('my-component').dispatchEvent('click');
Barney Carroll
@barneycarroll
Jul 23 2019 00:12 UTC
JESUS
Dominic Gannaway
@trueadm
Jul 23 2019 00:13 UTC
^^ yeah because that's what really happens in any real app, not!
Barney Carroll
@barneycarroll
Jul 23 2019 00:13 UTC
That's the single worst thing about working with React
Dominic Gannaway
@trueadm
Jul 23 2019 00:13 UTC
it's not even React, it's every framework and library today
with Flare I actually came up with a new system for this
each Responder exports a DEV only object that contains a set of methods for testing
Barney Carroll
@barneycarroll
Jul 23 2019 00:14 UTC
Trying to respect your fellow worker while you grab them by the throat and say why the fuck are you writing this nonsense test and they respond GOD KNOWS
Dominic Gannaway
@trueadm
Jul 23 2019 00:15 UTC
const testResponder = getComponent('my-component').getResponder({ input: 'finger' })
testResponder
  .press(150)
  .moveTo(getComponent('my-component2'), 100)
  .release()
behind the scenes, for the web it would appropiately call
pointerdown, touchstart, mousedown, touchmove, pointermove, mousemove, touchend, pointerup, mouseup
all with the relevant w3 spec properties
no frameworks or library cares about this today, but this is how it should be done!
declaratively written tests that conform to a specification!
you're not writing what your app should expect, you're writing what the user would do in a scenario. The outcome of the test should be that of the expectation of your code, not the binding between the fact you have an event listener and you're calling and event.
Which is how every library and framework is doing it today.
Gilbert
@gilbert
Jul 23 2019 00:26 UTC
yeah true, I usually write my components in such a way so that I don't have to deal with events when testing
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:27 UTC
Yeah, that's my general goal, too.
Barney Carroll
@barneycarroll
Jul 23 2019 00:28 UTC
It's absurd
Dominic Gannaway
@trueadm
Jul 23 2019 00:28 UTC

I don't understand why you wouldn't want to. Events are as important as the UI itself.

In fact, without events, you just have a static interface. Which is ironically where the web came from originally.

Claudia Meadows
@isiahmeadows
Jul 23 2019 00:29 UTC
More accurately, I care about events and the resulting tree, but I treat it as a black box.
I would love to decouple events from nodes and conceptual units, though.
Barney Carroll
@barneycarroll
Jul 23 2019 00:30 UTC
@isiahmeadows decouple conceptual units from...
Non-conceptual units?
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:30 UTC
Conceptual units = Components, DOM nodes, etc.
Dominic Gannaway
@trueadm
Jul 23 2019 00:31 UTC
I think this comes down to people's histoy with the web. On React Native, native Swift, native Obj C etc, people expose and use gestures in very rich forms. 75% of your test code will be wiring up event logic to ensure things work like they should.
Barney Carroll
@barneycarroll
Jul 23 2019 00:31 UTC
Ah
Right
The web has proved terrible for this
But you're looking at establishing a better underlying language?
Dominic Gannaway
@trueadm
Jul 23 2019 00:32 UTC
On those platforms there aren't "event listeners" and you don't register "click", you actually write very explicit code that means you need to say what is required for a "press" to occur. Including co-ords or targets, length of time, etc
This is why native app development has powered ahead of web in recent years. When was the last time you had a native app that didn't have a button work when you pressed it?
On the web, yesterday, the new Twitter website wouldn't work with my Apple Pencil on my iPad ...
it messed up scrolling completely.
Barney Carroll
@barneycarroll
Jul 23 2019 00:34 UTC
Cultural problem
Dominic Gannaway
@trueadm
Jul 23 2019 00:34 UTC

But you're looking at establishing a better underlying language?

new primitives

Claudia Meadows
@isiahmeadows
Jul 23 2019 00:34 UTC
So is this more like you're subscribing to events that happen to have a particular name + target (or set of them), instead of subscribing to a single event on a single node?
Dominic Gannaway
@trueadm
Jul 23 2019 00:35 UTC
With React Flare, a "PressResponder" listens to around 4 target events, then another 5 root events upon a press beginning. After a release, the 5 root events get unregistered.
Barney Carroll
@barneycarroll
Jul 23 2019 00:35 UTC
Twitter provides a comically bad user experience to anybody not using the closed system where consumer experience is better controlled.
Dominic Gannaway
@trueadm
Jul 23 2019 00:35 UTC
Flare doesn't actually use "click" to trigger any press events
it uses "pointerdown" and "pointerup"
and then calculates the target/client rect regions
Barney Carroll
@barneycarroll
Jul 23 2019 00:36 UTC
It's not that web tech is incapable of providing what we took for granted 20 years ago, it's a cultural political decision
Dominic Gannaway
@trueadm
Jul 23 2019 00:36 UTC
this is important too, because on touch you have something called a hit slop
on touch devices, even if you don't press on something, it gives you a bigger box so you have a better UX
say 20px extra
with React Flare, we do this for you automatically
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:37 UTC
@barneycarroll Mostly political and idealism. The failure of web components is probably the biggest example of that.
Dominic Gannaway
@trueadm
Jul 23 2019 00:37 UTC
so you can press something with your finger, and it just works like a native app
the difference in UX is huge. How many times have you tried to press that link on mobile Chrome/Safari, but missed?
that doesn't happen in a native app... I wonder why?
we also don't listen to "click" because it's throttled on the web and mobile
because the web has a really shit concept of "double click", you have to wait 750ms before a click registers
on mobile it's around 400ms, but can be shortened with pointer-events, but that doesn't work properly on Safari
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:39 UTC
@trueadm So is it fundamentally just a {eventNames, receiver} pair you can compose?
Under the hood?
Dominic Gannaway
@trueadm
Jul 23 2019 00:40 UTC
for what sorry?
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:40 UTC
For the responders in how they connect to events.
Dominic Gannaway
@trueadm
Jul 23 2019 00:40 UTC
well, yeah, there's a redesign PR that makes this clearer
context.dispatchEvent('onPress', eventObject, DiscreteEvent);
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:41 UTC
Of course, I'm glossing over state management and everything, but I see you picked up on that.
Dominic Gannaway
@trueadm
Jul 23 2019 00:41 UTC
it then bubbles that up in the tree, finds a hook with the same name "onPress", gets its listener and fires it
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:43 UTC
Makes me wonder how easy it'd be to make the responder connection implicit.
Dominic Gannaway
@trueadm
Jul 23 2019 00:43 UTC
responders also have an owernship model too
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:43 UTC
How so?
Dominic Gannaway
@trueadm
Jul 23 2019 00:43 UTC
where a responder will request ownership and upon taking it, block all other events from occuring on the page
this is important, because React Native, Android and iOS have this model today
so when you "drag" something
you don't accidently start typing into an input or scroll the screen
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:44 UTC
Makes sense.
Dominic Gannaway
@trueadm
Jul 23 2019 00:45 UTC
the reason why there's an explicit connection between responders and listeners is because of conflict
we had another team create their own user-land responder for FocusScope
a very popular concept right now about containing focus within a modal
they used onFocusWithin
and our responder did too
the conflict resulted in a bunch of bugs
plus our Flow types were any because it's hard to be monomorphic on types when an event listener (like the DOM) accepts anything
so we settled on responders having a "type" connection with the listener
which made for much safer types, and much safer runtime assertions
plus less bugs
Claudia Meadows
@isiahmeadows
Jul 23 2019 00:47 UTC
I meant making the responder= attribute itself implied.
Now that you explained the connection side, I feel I misstated my question.
I was wondering why an explicit responder= attribute would be necessary, as opposed to internalizing all that logic entirely and just exposing a means to components of subscribing to events within the tree.
Dominic Gannaway
@trueadm
Jul 23 2019 00:51 UTC
because you'd rather decleare responder, so it's better to be explicit with intent
funtion MyComponent() {
  return <div responders={[<PressResponder/>, <FocusResponder />, <HoverResponder />]} />
}
you're saying: I opt my component into only these responders. That contract is really important as you scale apps.
Otherwise you end up having listeners capture events for things they aren't sure about.
Also: as each responder has its own state machine, it means you properly ensure that the tree is met
we have a heuristic with Flare that means that if an event from a responder propagates through the tree and doesn't hit a listener but hits another responder on a host component of the same type, it terminates.
This is really important, as this allows for nested pressable controllers etc.
Also Flare events do not have event.preventDefault or event.stopPropagation
it was a terrible thing having them in the DOM events, so we removed them from Flare
they're imperative pieces of crap that break apps all over as they're non-deterministic and side-effectful
Dominic Gannaway
@trueadm
Jul 23 2019 00:56 UTC
instead you declaratively specific these things
function MyComponent() {
  return <div responders={<PressResponder preventDefault={true} />} />
}
which also allows for SSR replayability
(where you capture events that occur on the DOM before the framework/library has hydrated the components, then replay the events to the framework)
Claudia Meadows
@isiahmeadows
Jul 23 2019 01:00 UTC
How would you enable conditionally preventing the default action, as necessary for routing? Here's an example from React Router, where even independent of the onclick logic, it has to prevent the default action in order to route without the browser changing the location on its own afterwards and screwing up the router state.
Dominic Gannaway
@trueadm
Jul 23 2019 01:06 UTC
Pass a prop to MyComponent that sets preventDefault?
by default though, PressResponder does all those things you mention from React Router inside the PressResponder implementation
Claudia Meadows
@isiahmeadows
Jul 23 2019 01:07 UTC
In that case, it won't prevent the default action on right click, ctrl + click, or any of that. (It won't route, either.)
Does that also include verifying target === "_self" or no target?
when you use target === "_self", you'd pass that as a prop, as we do on FB5 at Facebook
Anway, I'm off now. Good night!
Claudia Meadows
@isiahmeadows
Jul 23 2019 01:14 UTC
Good night! Found and followed you on Twitter, BTW.
spacejack
@spacejack
Jul 23 2019 01:46 UTC
Really interesting insights! thanks for that info dump.
spacejack
@spacejack
Jul 23 2019 01:56 UTC
Though since I'm typically writing for browsers, I can't say I'd want to have platform abstractions in the library I'm using.
They're interesting ideas for cross platform apps though, so it's good to know what's going on in that space if I need to build a 'native' app.
Mobile touch in browsers is extremely limiting though and that limits your creative options for touch UIs. Basically, don't try anything too ambitious because native gesture overrides will probably break it at some point.
spacejack
@spacejack
Jul 23 2019 02:03 UTC
If sophisticated touch gestures are key to your app, I think I wouldn't target the web at all.
Claudia Meadows
@isiahmeadows
Jul 23 2019 02:12 UTC
Not the only one who noticed. :wink:
spacejack
@spacejack
Jul 23 2019 02:21 UTC
@isiahmeadows do you have a preference for #2479 ? I don't mind working on it.
Claudia Meadows
@isiahmeadows
Jul 23 2019 02:22 UTC
@spacejack Look at my solution comment.
That's my preference, but I don't care if you put it together and test for it.
spacejack
@spacejack
Jul 23 2019 02:22 UTC
Ok
spacejack
@spacejack
Jul 23 2019 02:28 UTC
How would you treat the types for methods like _map, unregisterChild, changing, parents? Are those internals?
Claudia Meadows
@isiahmeadows
Jul 23 2019 02:28 UTC

@spacejack

Though since I'm typically writing for browsers, I can't say I'd want to have platform abstractions in the library I'm using.

Agreed, but moderately. I'd rather provide the primitives to enable those abstractions rather than provide the abstractions themselves, especially if they aren't useful for all levels of scale beyond that which you might as well just write it all in HTML with a little bit of JS. Mithril should be more like LLVM + Clang, letting someone come up with a Rust if they so choose. It shouldn't be just another GHC that does everything from the high-end API to the low-end opcode generation and isn't pluggable at all.

spacejack
@spacejack
Jul 23 2019 02:29 UTC
lol that analogy
Claudia Meadows
@isiahmeadows
Jul 23 2019 02:29 UTC
@spacejack Yes, those are all internals. If it's undocumented, it's private. While you're at it, feel free to underscore those internal members that aren't public.
spacejack
@spacejack
Jul 23 2019 02:30 UTC
:thumbsup:
Yeah at the very least you want to be able to do server-side rendering so some platform abstract-ability is certainly useful.
Claudia Meadows
@isiahmeadows
Jul 23 2019 02:38 UTC

More accurately, I'd want Mithril to be more like OCaml's front end and back end. OCaml has a front end that provides the syntax and allows for some high-level optimization, and a back end that compiles the AST, types, etc. into an executable program. It provides defaults, but replacements exist for each component.

  • ReasonML can replace the front end.
  • js_of_ocaml and BuckleScript both can replace the backend.

With my redesign, it'd end up similar.

  • Front ends: hyperscript and JSX. Mithril would be unopinionated here.
  • Back ends: DOM, SSR, and resolved vnode tree (for testing).

A user might choose to create other renderers (like to native elements), but that would be mostly up to the user.

spacejack
@spacejack
Jul 23 2019 02:46 UTC
Those other renderers would need to abstract events somehow
Claudia Meadows
@isiahmeadows
Jul 23 2019 02:49 UTC
The event abstraction is something I planned before abstracting the renderer. It's called bringing components and DOM elements into the same general model so it's less to think about. They're events, but you don't need to care as much about how to listen to them.
James Forbes
@JAForbes
Jul 23 2019 03:16 UTC
Abstracting away the browser API to have a generic reusable interface across various platforms reminds of Java Applets. Maybe this time it will be amazing.
Scotty Simpson
@CreaturesInUnitards
Jul 23 2019 03:27 UTC
:point_up:
I’m really curious. Not holding my breath, but curious for sure.
Claudia Meadows
@isiahmeadows
Jul 23 2019 03:33 UTC
@JAForbes This is why I'm skeptical of implementing a completely new system over what's currently there. I don't want to repeat the same mistake that was that, and I don't want to repeat the failed project that tried to entirely replace and reimplement the DOM using canvas APIs (can't find the project - this was years ago and it was atrocious on mobile. I believe it started with an f and its domain was a domain hack, but I can't remember anything beyond that).
spacejack
@spacejack
Jul 23 2019 03:52 UTC
Oh man I forgot how much I hate working with plain javascript...
Adding underscores in stream.js is fraught with peril
(The tests are good though, they caught my errors)
just one of those things I don't have to think about in typescript
I can't think of any new tests to add really. Think I'll just PR this as-is
Arp Lee
@arxii
Jul 23 2019 04:07 UTC
the request module is does not have any payload in chrome dev tools, not sure what i'm doing wrong...
just trying to send a json post body
spacejack
@spacejack
Jul 23 2019 04:11 UTC
@arxii what version of mithril? For V1 you send a data property, in V2 you send a body property
Claudia Meadows
@isiahmeadows
Jul 23 2019 04:11 UTC
@spacejack Yeah, for that particular change, I'm not worried if you don't add new tests.
spacejack
@spacejack
Jul 23 2019 04:12 UTC
(maybe we should have a deprecation warning for request with data property...)
BTW to make this change work, I had to leave some of the original logic in-tact, so I couldn't follow your suggestion exactly
I think you had the condition reversed (which confused me too)
the original test was ignoreInitial !== Stream.SKIP not ===
Arp Lee
@arxii
Jul 23 2019 04:16 UTC
ok...data works but my version is v2...
Claudia Meadows
@isiahmeadows
Jul 23 2019 04:17 UTC
@spacejack I'll take a look. My logic may have been wrong, but I would've noticed very quickly when tests failed. :wink:
Claudia Meadows
@isiahmeadows
Jul 23 2019 04:18 UTC
Correct it to use if for consistency.
spacejack
@spacejack
Jul 23 2019 04:18 UTC
Oh nevermind that I read it wrong
lol
Yes ok I'll do that
Claudia Meadows
@isiahmeadows
Jul 23 2019 04:21 UTC
Also, while you're at it, see if you can move the stream._state === "active" here to the callee in stream.map and just branch off of ignoreInitial.
That's what I was trying to go for in my comment in #2479, trying to simplify the condition.
I misread the code and put it in the wrong place previously in my suggestion.
Arp Lee
@arxii
Jul 23 2019 04:23 UTC
yea ur npm repo is outdated
spacejack
@spacejack
Jul 23 2019 04:23 UTC
@arxii V1 is the current official version. Sorry, the docs on the site say V2 but it's still an RC.
Arp Lee
@arxii
Jul 23 2019 04:24 UTC
ok
spacejack
@spacejack
Jul 23 2019 04:25 UTC
You can npm i mithril@next to get V2
Claudia Meadows
@isiahmeadows
Jul 23 2019 04:25 UTC
And matter of fact, the site specifically recommends that.
Arp Lee
@arxii
Jul 23 2019 04:25 UTC
oh cool i didnt know i could do that... i did git+https://github.com/MithrilJS/mithril.js.git#v2.0.0-rc.9
spacejack
@spacejack
Jul 23 2019 04:26 UTC
You can install that rc from npm instead of github with npm i mithril@next
Arp Lee
@arxii
Jul 23 2019 04:27 UTC
: )
RebootCode
@rebootcode
Jul 23 2019 09:02 UTC
Is it possible to do if else inside component to show different content on different condition?
like
view: function() {
    return m("div", [
        if (auth) {
            m("Login", m("a", .....
        } else {
            m("Hello User A", ....
       }
    ])
}
I am getting error when I do so!
Oscar
@osban
Jul 23 2019 09:18 UTC
@rebootcode you'd need to return another array with vnodes in this case, but recommended is using a ternary, so something like:
view: function() {
    return m("div", [
        auth
        ?  [m("Login", m("a", .....]
        :  m("Hello User A", ....
    ])
}
RebootCode
@rebootcode
Jul 23 2019 10:12 UTC

@osban - Thank you so much - I did exactly same and it worked - I forgot to reply and update here!

Thanks a lot :)

Oscar
@osban
Jul 23 2019 10:12 UTC
@rebootcode :+1:
RebootCode
@rebootcode
Jul 23 2019 10:14 UTC
What is the best way to tackle "materializecss" -- href "#!" element that triggers javascript like "Dropdown"

like one here - https://materializecss.com/dropdown.html

It's really painful working with these component in mithril

this automatically takes it to home route
m("li",
    m("a.dropdown-trigger[data-target='dropdown1'][href='#!']", ["Dropdown",
        m("i.material-icons.right", "arrow_drop_down")
    ])
)
Oscar
@osban
Jul 23 2019 10:15 UTC
did you see this example? It's for a side menu, but you could probably adjust it for a dropdown
RebootCode
@rebootcode
Jul 23 2019 10:16 UTC
Yes, but it's way too much code for simple things like these!
I did use them for Sidenav. But, repeating same process for Dropdown, I think there should be some easy onclick: way
Oscar
@osban
Jul 23 2019 10:18 UTC
hmm, what if you return false from the onclick?
RebootCode
@rebootcode
Jul 23 2019 10:18 UTC
I am trying them out :thumbsup:
Patrik Johnson
@orbitbot
Jul 23 2019 10:45 UTC
@rebootcode maybe have a look at polythene, which is material design for mithril & react - should come with existing components for a lot of stuff
Oscar
@osban
Jul 23 2019 10:46 UTC
@rebootcode it seems to (kinda) work like this
not sure how to fix the location of the dropdown itself
Oscar
@osban
Jul 23 2019 11:00 UTC
oh, apparently the location is how it's supposed to be... 🤔
Oscar
@osban
Jul 23 2019 11:08 UTC
there needs to be an a tag inside the li: flems
Oscar
@osban
Jul 23 2019 11:21 UTC
and it turns out you can drop the href altogether, so no issues there
James Forbes
@JAForbes
Jul 23 2019 12:01 UTC
I'm trying to port a 0.2x app to 1.x and I'm finding context.onunload doesn't exactly translate to { oncreate, onremove }. Because you might create some event listeners in the closure of the create you won't have access to in the onremove. It's a little awkward. Any patterns y'all recommend?
Oscar
@osban
Jul 23 2019 12:03 UTC
maybe create in the closure, but call in oncreate?
James Forbes
@JAForbes
Jul 23 2019 12:04 UTC
yeah... except these are just inline in the view, so there's not really a closure to speak of
there could be though
writing to vnode.state is a possibility I guess...
actually!
Can you do this:
m('div', {
  oncreate(vnode){
    vnode.onremove = () => { ... }
  }
})
reliably?
Oscar
@osban
Jul 23 2019 12:06 UTC
haha, no idea...don't see why not, though
James Forbes
@JAForbes
Jul 23 2019 12:07 UTC
haha great thanks 😀
Barney Carroll
@barneycarroll
Jul 23 2019 12:23 UTC
That vnode will be discarded in the next loop @JAForbes
James Forbes
@JAForbes
Jul 23 2019 12:28 UTC
haha fun
I'm thinking a hook factory then?
Barney Carroll
@barneycarroll
Jul 23 2019 12:29 UTC
Inline component mate ;P
James Forbes
@JAForbes
Jul 23 2019 12:29 UTC
yeah maybe, trying to keep this branch focused, but yeah maybe
but did we remove onunload without considering this?
surely there's some nice approach
Barney Carroll
@barneycarroll
Jul 23 2019 12:31 UTC
This is kinda what closure components were all about
And what is just so much worse in React pre-hooks
Sharing references between lifecycles is a PITA
James Forbes
@JAForbes
Jul 23 2019 12:32 UTC
yeah but, v0.2x had a pretty good solution
without relying on components
wow was it ahead of it's time or what?
@barneycarroll vnode.state persists doesn't it?
Barney Carroll
@barneycarroll
Jul 23 2019 12:33 UTC
Oh yeah definitely
You can always attach anything you want to that
Andrea Coiutti
@ACXgit
Jul 23 2019 12:34 UTC
@JAForbes just a curiosity... why are you upgrading to 1.x instead to go straight for 2.x?
James Forbes
@JAForbes
Jul 23 2019 12:34 UTC
so:...
{
  oncreate(){
    vnode.state.onremove = ...
  },
  onremove(){
    vnode.state.remove()
  }
}
Barney Carroll
@barneycarroll
Jul 23 2019 12:35 UTC
Yeah you typoed the reference in the first function but :+1:
Oscar
@osban
Jul 23 2019 12:35 UTC
both should have the same name :wink:
James Forbes
@JAForbes
Jul 23 2019 12:35 UTC
thanks eslint @osban @barneycarroll 😂
Oscar
@osban
Jul 23 2019 12:35 UTC
lol
James Forbes
@JAForbes
Jul 23 2019 12:36 UTC
@ACXgit it's not released yet, I'll probably wait 6 months to a year before going to v2. I think it's awesome how quick y'all jump on it though, I really appreciate it. I've already used v1 a bunch and feel confident in its stability.
Andrea Coiutti
@ACXgit
Jul 23 2019 12:38 UTC
migrating from 1.x to 2.x shouldn't be much drama anyways
James Forbes
@JAForbes
Jul 23 2019 12:38 UTC
yeah seems like it
Andrea Coiutti
@ACXgit
Jul 23 2019 12:38 UTC
you are already doing most of the work now
James Forbes
@JAForbes
Jul 23 2019 12:39 UTC
yeah, I'm half updating stuff half building a compatibility layer
wish I didn't need the compat layer, but I've tried this 4-5 times now, the app is to big, something weird happens whenever I try to bulk update interfaces
so far the compat layer is working well
just simple stuff
Oscar
@osban
Jul 23 2019 12:40 UTC
if you want to be prepared for a potential removal of vnode.state in the future, you might wanna use a closure :stuck_out_tongue_winking_eye:
James Forbes
@JAForbes
Jul 23 2019 12:40 UTC
hard in this particular instance...
it's not a component
Andrea Coiutti
@ACXgit
Jul 23 2019 12:41 UTC
why does everybody hate vnode.state now :smile:
James Forbes
@JAForbes
Jul 23 2019 12:41 UTC
lol I always did
image.png
Oscar
@osban
Jul 23 2019 12:41 UTC
I don't hate it, but I don't use it either :wink:
Andrea Coiutti
@ACXgit
Jul 23 2019 12:41 UTC
I remember that
James Forbes
@JAForbes
Jul 23 2019 12:42 UTC
it exists as a channel to pass state across methods, it's just noise compared to closures
it's slightly better than this
Andrea Coiutti
@ACXgit
Jul 23 2019 12:42 UTC
what's the main reason to avoid it from your perspective?
James Forbes
@JAForbes
Jul 23 2019 12:42 UTC
just less boilerplate in passing state across boundaries
it's fine it's just not nice
it's more like, what's a justification to use it when we have closures, as opposed to the opposing framing
Andrea Coiutti
@ACXgit
Jul 23 2019 12:43 UTC
I have to admit that the main reason I'm still using it is only to get rid of one level of indentation in components :laughing:
Oscar
@osban
Jul 23 2019 12:43 UTC
lol
James Forbes
@JAForbes
Jul 23 2019 12:43 UTC
a solid reason 😂
Andrea Coiutti
@ACXgit
Jul 23 2019 12:45 UTC
in main components I end to write things like this:
const Component = {}

Component.oninit = ({ attrs: va, state: vs }) => {}

Component.view = ({ attrs: va, state: vs }) => {}
just to keep things flatter
and using va and vs as shortenings reduces the boilerplate a lot
James Forbes
@JAForbes
Jul 23 2019 12:48 UTC
Yeah to each their own for sure
Andrea Coiutti
@ACXgit
Jul 23 2019 12:49 UTC
other reasons for vnode.state being the new public enemy?
spacejack
@spacejack
Jul 23 2019 12:50 UTC
vnode.state won't go away for a long time
V3 is who knows when :)
Oscar
@osban
Jul 23 2019 12:50 UTC
I think it's just unnecessary with closures
James Forbes
@JAForbes
Jul 23 2019 12:50 UTC
that's all I've got, except maybe, mutation is nice to avoid where possible, vnode.state makes that very difficult. In a closure I'll set up some streams and scan them, but I never reassign anything
vnode.state also just feels like a state bag of old, hard to infer the shape/inteface type
a closure, you just have bare variable names, there's no guessing about the possibility space of what's available
Andrea Coiutti
@ACXgit
Jul 23 2019 12:51 UTC
that's a fair point, with vnode.state you have to pay more attention assigning things, and is more error-prone
James Forbes
@JAForbes
Jul 23 2019 12:53 UTC
oh and, I use jump to definition, and rename symbol and vscode/typescript features like that, it's harder to do that with vnode.state without some elbow grease
it just happens for free with a closure because it's inferred
Andrea Coiutti
@ACXgit
Jul 23 2019 12:53 UTC
tomorrow I'll get my hands on a new 32" monitor... maybe indentation won't be a real problem then and I'll convert to closures too :laughing:
Oscar
@osban
Jul 23 2019 12:54 UTC
lol
yeah 32" (and 4K) is very nice
James Forbes
@JAForbes
Jul 23 2019 12:55 UTC
ironically I've found mutation tends towards indentation because you need ambient context
Andrea Coiutti
@ACXgit
Jul 23 2019 12:55 UTC
I opted for a 2k... the dot pitch of the 4k is too small for nighttime tinkering
James Forbes
@JAForbes
Jul 23 2019 12:55 UTC
where as FP, most of the work can just be top level functions
sorry edited
spacejack
@spacejack
Jul 23 2019 12:56 UTC
@ACXgit if you don't want indents...
function C() {
    const foo = 'abc'

    function oncreate(v) {
        ...
    }

    function view(v) {
        return m(...)
    }

    return {oncreate, view}
}
(though vnode types won't be inferred that way)
Andrea Coiutti
@ACXgit
Jul 23 2019 12:58 UTC
not bad
btw, anyone here working on an ultrawide monitor?
spacejack
@spacejack
Jul 23 2019 12:59 UTC
Not really, I only have 2560px across :)
Andrea Coiutti
@ACXgit
Jul 23 2019 13:00 UTC
I was pondering to buy an ultrawide but 1) not a big fan of curved screens and 2) they are damn expensive
James Forbes
@JAForbes
Jul 23 2019 13:00 UTC
i work on my 11" almost exclusively, used to be 10"
spacejack
@spacejack
Jul 23 2019 13:00 UTC
I can't live without my 2K monitor
Andrea Coiutti
@ACXgit
Jul 23 2019 13:01 UTC
functional people on dysfunctional monitors :smile:
spacejack
@spacejack
Jul 23 2019 13:02 UTC
@ACXgit but it's cheaper than an ultrawide for a bit more space than a normal monitor
Oscar
@osban
Jul 23 2019 13:02 UTC
no ultrawide here either
James Forbes
@JAForbes
Jul 23 2019 13:02 UTC
I don't know what y'all are looking at 😀
Andrea Coiutti
@ACXgit
Jul 23 2019 13:02 UTC
@spacejack I bought a 2k 16:9 too
spacejack
@spacejack
Jul 23 2019 13:02 UTC
ah
James Forbes
@JAForbes
Jul 23 2019 13:02 UTC
mobile first right?
😀
Andrea Coiutti
@ACXgit
Jul 23 2019 13:03 UTC
at the end it seemed to me the best compromise
spacejack
@spacejack
Jul 23 2019 13:03 UTC
Mobile?? I don't make anything for mobile these days, haha
Andrea Coiutti
@ACXgit
Jul 23 2019 13:03 UTC
at least until price of ultrawide monitors drop
I have a big respect for @barneycarroll who is able to code on mobile all the time
when he drops code snippets here answering to questions
I barely manage to write plain sentences on Gitter mobile app
Barney Carroll
@barneycarroll
Jul 23 2019 14:17 UTC
@ACXgit those days are long gone I'm afraid
Scotty Simpson
@CreaturesInUnitards
Jul 23 2019 14:38 UTC

Wait, WHAT?!?
@JAForbes is ditching 0.2
@barneycarroll is ditching code-by-phone

La Belle Époque is finally, truly over 😢

Barney Carroll
@barneycarroll
Jul 23 2019 14:42 UTC
The third angel sounded
And a star fell from heaven
Burning as it were a lamp
And it fell upon the fifth part of the waters
Scotty Simpson
@CreaturesInUnitards
Jul 23 2019 14:58 UTC
Wait, the FIFTH part?
Call me wormwood
Oscar
@osban
Jul 23 2019 15:04 UTC
if I hear that @CreaturesInUnitards is ditching comma-first, the end of the world must be near...
Barney Carroll
@barneycarroll
Jul 23 2019 15:06 UTC
Haggard old @CreaturesInUnitards
James Forbes
@JAForbes
Jul 23 2019 15:08 UTC
v0.2x so good though, rethinking this decision, where's subtree retain 😂
Barney Carroll
@barneycarroll
Jul 23 2019 15:10 UTC
{subtree: "retain"} was so impractical for most scenarios
James Forbes
@JAForbes
Jul 23 2019 15:12 UTC
I used it 1 time, but it was a good time 😀
Oscar
@osban
Jul 23 2019 15:12 UTC
TMI
Patrik Johnson
@orbitbot
Jul 23 2019 15:14 UTC
:eyes:
Scotty Simpson
@CreaturesInUnitards
Jul 23 2019 15:19 UTC

TMI

ROFLMAO 🤣

James Forbes
@JAForbes
Jul 23 2019 15:20 UTC
I'm starting the 0.2x gitter
/leave
Scotty Simpson
@CreaturesInUnitards
Jul 23 2019 15:29 UTC
Lol
Aww
(FWIW: it was a @JAForbes code snippet that opened my eyes to the OVERWHELMING, INARGUABLE BENEFITS of comma-first notation.)
Oscar
@osban
Jul 23 2019 15:32 UTC
lol
Barney Carroll
@barneycarroll
Jul 23 2019 15:51 UTC
Perfect. Let's keep this room for comma style debates and React architecture critique, and use the 0.2 room for
Tabs vs spaces
Patrik Johnson
@orbitbot
Jul 23 2019 16:00 UTC
var vs let
eeh, prolly too ES6 for that room, on second thought
trailing ;s?
Scotty Simpson
@CreaturesInUnitards
Jul 23 2019 16:01 UTC
No, ASI is carved in stone
Patrik Johnson
@orbitbot
Jul 23 2019 16:08 UTC
shoo, that should be in the 0.2 chat
Andrea Coiutti
@ACXgit
Jul 23 2019 16:15 UTC
new monitor arrived, vertical line of black pixels in the middle - not today, closure components
Patrik Johnson
@orbitbot
Jul 23 2019 16:16 UTC
:cry:
do you have a tv?
Andrea Coiutti
@ACXgit
Jul 23 2019 16:17 UTC
a Panasonic Plasma... too much carbon footprint even for closures
Patrik Johnson
@orbitbot
Jul 23 2019 16:17 UTC
I bought my first one in almost a decade and it's a 4k 44" one, that'd probably handle a lot of widescreen issues... :wink:
Oscar
@osban
Jul 23 2019 16:17 UTC
ouch 🙁
Andrea Coiutti
@ACXgit
Jul 23 2019 16:18 UTC
this is the second monitor I have to send back, first a Iiyama and now a BenQ
Oscar
@osban
Jul 23 2019 16:18 UTC
I ditched my tv when I bought my projector + screen
Andrea Coiutti
@ACXgit
Jul 23 2019 16:18 UTC
Amazon Marketplace is a sort of wild west
Patrik Johnson
@orbitbot
Jul 23 2019 16:18 UTC
I also managed to drop the dang stand on the screen when I bought a monitor (2k 24 inch) so now I have a nice speck that doesn't change color at all
but you get to return defective items, then, I gather?
the stand mishap was on me, since I managed to do it myself when setting things up
Andrea Coiutti
@ACXgit
Jul 23 2019 16:25 UTC
yes I'm going to return it as soon as possible
Barney Carroll
@barneycarroll
Jul 23 2019 16:47 UTC
Semicolons only ever allowed preceding array expressions
Andreas Ekeroot
@Rembane
Jul 23 2019 17:17 UTC
Good morning, Are there any examples on how to use m.request in Mithril while programming in Typescript?
Oscar
@osban
Jul 23 2019 17:25 UTC
@Rembane I think:
m.request<{data: User[]}>({
    method: "GET",
    url: "https://rem-rest-api.herokuapp.com/api/users",
    withCredentials: true
})
taken from here
@spacejack is the residential typescript expert
Andreas Ekeroot
@Rembane
Jul 23 2019 17:46 UTC
@osban Thank you!
Mike McRill
@thequailman
Jul 23 2019 17:53 UTC
how do I specify multiple targets for ospec?
running something like this, it only runs the first file (which sets up the global mocks)
npx ospec 'src/index_test.js' './src/utilities/*_test.js'
Barney Carroll
@barneycarroll
Jul 23 2019 17:53 UTC
What do you mean by 'target', Mike?
Mike McRill
@thequailman
Jul 23 2019 17:54 UTC
multiple files to test, sorry
I want the index_test.js file tested, as well as everything under utilities
Oscar
@osban
Jul 23 2019 17:55 UTC
@Rembane :+1:
Mike McRill
@thequailman
Jul 23 2019 17:55 UTC
the index_test.js file just contains mocks for global.window stuff, and when I run that ospec command it returns:
All 0 assertions passed in 3ms
Barney Carroll
@barneycarroll
Jul 23 2019 18:07 UTC
That's odd - it should work according to documentation
Mike McRill
@thequailman
Jul 23 2019 18:09 UTC
right, I looked through the code and it seems like there's possibly a globs arg?
I'm not super familiar with arg parsing in javascript
spacejack
@spacejack
Jul 23 2019 18:10 UTC
process.argv[] is just an array of cli params
I'm working around it now using excludes, just kinda weird
ospec is great though, only thing missing is code coverage :grin:
Patrik Johnson
@orbitbot
Jul 23 2019 18:23 UTC
IIRC ospec has some filepath weirdness where it only looks into tests/ subfolders by default or something like that
though that might be outdated...
huh, gitter issues again, just a moment ago it updated the last 30 mins of comments
so yeah, nvm above...
Mike McRill
@thequailman
Jul 23 2019 18:33 UTC
hmm
so it works if I run:
$ node node_modules/ospec/bin/ospec './src/index_test.js' './src/utilities/GetDate_test.js'
––––––
The 1 assertion passed in 5ms
$ npx ospec './src/index_test.js' './src/utilities/GetDate_test.js`
––––––
All 0 assertions passed in 3ms
Patrik Johnson
@orbitbot
Jul 23 2019 18:36 UTC
what's the CWD for npx commands?
probably some difference in where it's actually looking for files
you could verify with passing the absolute path
Mike McRill
@thequailman
Jul 23 2019 18:38 UTC
it's finding them
otherwise it would say Error: Cannot find module
Patrik Johnson
@orbitbot
Jul 23 2019 18:43 UTC
hmm hmm. what's the version for the npx command?
might be worth verifying if there's a difference in the implementations being run
Mike McRill
@thequailman
Jul 23 2019 18:44 UTC
6.9.0
Patrik Johnson
@orbitbot
Jul 23 2019 18:45 UTC
does that match whatever you have installed in node_modules?
Mike McRill
@thequailman
Jul 23 2019 18:45 UTC
you mean for ospec?
ospec doesn't print any version info
Patrik Johnson
@orbitbot
Jul 23 2019 18:46 UTC
yeah, I know, would be interested in what it's actually pulling
Mike McRill
@thequailman
Jul 23 2019 18:46 UTC
I'm not sure how to find that
Patrik Johnson
@orbitbot
Jul 23 2019 18:46 UTC
though from looking at the npx docs it should actually be trying to run whatever you have locally installed in node_modules anyways
Mike McRill
@thequailman
Jul 23 2019 18:46 UTC
also I added a console statement to node_modules/ospec/bin/ospec, the npx version doesn't seem to hit that file
Patrik Johnson
@orbitbot
Jul 23 2019 18:46 UTC
is it the same result as if you run the bin/ospec command manually?
Mike McRill
@thequailman
Jul 23 2019 18:47 UTC
yea from node?
if run it manually from node it's not the same, it works
$ node node_modules/ospec/bin/ospec './src/index_test.js' './src/utilities/GetDate_test.js'
––––––
The 1 assertion passed in 5ms
Patrik Johnson
@orbitbot
Jul 23 2019 18:48 UTC
ok, would assume npx weirdness in some manner
was this an actual problem or just random errors ?
you can easily put a working command in your npm scripts section anyways
Mike McRill
@thequailman
Jul 23 2019 18:50 UTC
seems like a bug with how ospec is packaged possibly
Patrik Johnson
@orbitbot
Jul 23 2019 18:50 UTC
dunno
Manabu Tokunaga
@imanabu
Jul 23 2019 18:50 UTC
{ key: "blah" } seems to be broken in 2.0.0-rc.9. Was it removed?
Patrik Johnson
@orbitbot
Jul 23 2019 18:51 UTC
from some quick digging, looks like npx run packages are downloaded to ~/.npm/_npx on a mac at least
so I would assume you could edit the source file there to see what's what
Mike McRill
@thequailman
Jul 23 2019 18:51 UTC
i see the same behavior if I use a script command in package.json though
i'm just using npx because I thought it was the same thing and allowed for more introspection
    "scripts": {
        "test": "ospec './src/index_test.js' './src/utilities/GetDate_test.js' --require esm"
 $ npm run test

> ospec './src/index_test.js' './src/utilities/GetDate_test.js' 
––––––
All 0 assertions passed in 2ms
Patrik Johnson
@orbitbot
Jul 23 2019 18:54 UTC
@imanabu not that I'm aware of, you could try checking the changelog on the mithril.js.org site - what kind of errors are you seeing?
IIRC there was a change that you cannot mix keyed and unkeyed elements any longer, so that's intentional if you're getting problems there
Mike McRill
@thequailman
Jul 23 2019 18:56 UTC
well I fixed it by changing ospec/package.json:
  "main": "ospec.js",
  "main": "./bin/ospec",
I'm not sure if this is right though
Patrik Johnson
@orbitbot
Jul 23 2019 18:57 UTC
🤔
this is in your local node_modules?
Mike McRill
@thequailman
Jul 23 2019 18:57 UTC
yea that's not right because it broke the test running
it does hit the console.log now though :)
Patrik Johnson
@orbitbot
Jul 23 2019 18:58 UTC
shouldn't the bin stuff be copied over into node_modules/.bin and be run from there?
by the npm commands, I mean, automatically
can't remember what the current state of the art should be with these things
Mike McRill
@thequailman
Jul 23 2019 18:59 UTC
yea I see it in there
Patrik Johnson
@orbitbot
Jul 23 2019 19:00 UTC
so, if you add a log to the .bin/folder, does the npm run script hit that file?
Mike McRill
@thequailman
Jul 23 2019 19:01 UTC
yea
so
I have ospec installed separately
and .bin is pointing to mithril/ospec/bin/ospec
not my separate ospec
Manabu Tokunaga
@imanabu
Jul 23 2019 19:01 UTC
@orbitbot Thank you. My be I am not using this right. I was also in the process of writing a Fiddle to demo this issue, and on 2.x it does not even run if there is a key: in there whereas in 1.x it does run the code but I cannot pull the key in an element event. Let me read further. I just wanted to check to make sure there is no breaking changes per-se. Thank you!
Mike McRill
@thequailman
Jul 23 2019 19:01 UTC
so it looks like ospec 3.1.0 works, the one in mithril rc9 doesn't
as far as multiple input files
Claudia Meadows
@isiahmeadows
Jul 23 2019 19:02 UTC
@imanabu If you're referring to key attributes, you should have an informative stack trace. :wink:
Manabu Tokunaga
@imanabu
Jul 23 2019 19:04 UTC
@isiahmeadows (sorry I accidentally clicked "report") intead of reply. Anyhow, let me dive in further and will provide detail if I am still stuck.
Patrik Johnson
@orbitbot
Jul 23 2019 19:05 UTC
hmm...
ospec 3.1.0. is what's in the mithril.js repo source on github...
though that's a pre-release also... perhaps
Mike McRill
@thequailman
Jul 23 2019 19:06 UTC
yep, got it figured out:
Error: Cannot find module 'ospec'
Require stack:
- //utilities/GetDate_test.js
- /node_modules/mithril/ospec/bin/ospec
i removed the ospec i had installed separately
I think this was related to the ESM removal work, I'll create a GH issue
thank you @orbitbot for poking around with me
Patrik Johnson
@orbitbot
Jul 23 2019 19:09 UTC
yeah, not really sure what's what here
np
dunno if ospec really should be in the mithril js npm package in the first place
looks like there might be a lot of arguably cruft left in what's in the npm module for mithril.js
Mike McRill
@thequailman
Jul 23 2019 19:11 UTC
actually no need for GH, I just changed my import to import o from "mithril/ospec"
Claudia Meadows
@isiahmeadows
Jul 23 2019 19:11 UTC
This message was deleted
Mike McRill
@thequailman
Jul 23 2019 19:11 UTC
everything's working :tada:
Claudia Meadows
@isiahmeadows
Jul 23 2019 19:12 UTC
I don't think ospec has been updated on npm since I removed ES module support.
Mike McRill
@thequailman
Jul 23 2019 19:12 UTC
one less import in my package.json, woohoo
Patrik Johnson
@orbitbot
Jul 23 2019 19:12 UTC
also I would treat is as pretty surprising that npm bin commands from deeply nested subfolders are even considered in the first place
npm install ospec gives 3.1.0
which is the version specified in the package.json folder
though not sure if that then should be 4.x ?
diff doesn't show any differences between 3.1.0 and what's downloaded with mithril @2.0.0-rc-9
by now I'm pretty lost... :slight_smile:
Claudia Meadows
@isiahmeadows
Jul 23 2019 19:16 UTC
@orbitbot Diff based on the latest ospec release. :wink:
It's going to be different.
Patrik Johnson
@orbitbot
Jul 23 2019 19:17 UTC
I thought I am
Claudia Meadows
@isiahmeadows
Jul 23 2019 19:17 UTC
Or at least it should. If it's not, I'll be deprecating the offending release. I'll be releasing a v4 for ospec alongside Mithril v2.
Patrik Johnson
@orbitbot
Jul 23 2019 19:17 UTC
3.1.0 is the latest ospec, right?
Mike McRill
@thequailman
Jul 23 2019 19:18 UTC
I think @orbitbot 's idea of moving ospec out of mithril proper may make sense in the future
Patrik Johnson
@orbitbot
Jul 23 2019 19:18 UTC
I was thinking npmignorefor anything not strictly necessary
Claudia Meadows
@isiahmeadows
Jul 23 2019 19:18 UTC
@orbitbot Yes, but the latest release was back in February. The ESM change was in May.
Patrik Johnson
@orbitbot
Jul 23 2019 19:18 UTC
think of all the wasted bits
@thequailman File an issue, and I'll look into it. I'd love to move this crap out of core - it's been at best 🤷‍♀️, at worst literally causing grief and slowing down development.
Mike McRill
@thequailman
Jul 23 2019 19:20 UTC
:+1:
Patrik Johnson
@orbitbot
Jul 23 2019 19:20 UTC
right, so none of the files I was diffing apparently were changed (ospec.js, bin/ospec, bin/ospec.cmd), only package.json stuff
a .npmignore might still be valid
Claudia Meadows
@isiahmeadows
Jul 23 2019 19:21 UTC
So anything past this would not be released.
Patrik Johnson
@orbitbot
Jul 23 2019 19:21 UTC
f.e. the examples folder is pulled down with the npm package
Oscar
@osban
Jul 23 2019 19:21 UTC
moving it out of core seems logical to me, imho
Claudia Meadows
@isiahmeadows
Jul 23 2019 19:21 UTC

@orbitbot I've considered it in the past, just to strip all the tests.

I'd rather keep docs/examples/ shipping, though.

And more generally, docs/. You never know when all of a sudden you need to look at the docs offline for whatever reason.
Manabu Tokunaga
@imanabu
Jul 23 2019 19:22 UTC
My "key" attribute issue might be linked to TypeScript... Will report the findings by writing .js first. Thanks everyone for your immediate help!
Patrik Johnson
@orbitbot
Jul 23 2019 19:22 UTC
guess the performance stuff might be stuff that could be removed at least :grinning:
and the bundler...
Mike McRill
@thequailman
Jul 23 2019 19:24 UTC
new question, how would I monkey patch a hostname to be prepended to m.request URLs?
for testing
I have a request function I've created that I can use pretty easily, but I'm just curious if there's a more native way
Patrik Johnson
@orbitbot
Jul 23 2019 19:25 UTC
think you might need to abstract away or pass the urls as parameters separately in prod and testing
or then actually monkeypatch m.request directly however you'd like
the source is pretty small, if you need to take a look
on the typescript topic :point_up: , werent' there some new specs for the RCs as well?
Oscar
@osban
Jul 23 2019 19:28 UTC
@thequailman the benefit of using an m.request wrapper is that you can easily switch host names
just change the host name in the wrapper and you're done
Patrik Johnson
@orbitbot
Jul 23 2019 19:33 UTC
@thequailman btw, wrt #2483 , there's some minorly voodoo git path commit history extraction magic from googling that'll strip everything else to set up a new repo that works reasonably well
I've done it a few times, kind of a rite of passage for advanced git stuff :wink:
Mike McRill
@thequailman
Jul 23 2019 19:34 UTC
@osban yea that's what I have/was going to do, just curious if there's some magical m.request global that I wasn't seeing for hostname :)
@orbitbot if you mean so I can move ospec to a separate repo, the main blocker for me is I can't create repos under mithril. if someone wants to setup a new ospec repo I can push to it, but I also have no idea how to move the integrations like npm
Oscar
@osban
Jul 23 2019 19:35 UTC
hahaha, not that I know
Patrik Johnson
@orbitbot
Jul 23 2019 19:37 UTC
off the top of my head the npm registry will eat anything as long as the account can push there, any repo urls etc. will in any case only be updated for future releases anyways
you're right wrt the official repo in the org, but the big task is mainly stripping files and commit history for the new repo
eg. npm repos are bundled locally and then uploaded to the registry, so there's really no concept of downloading from an authenticated source or server or whatnot
spacejack
@spacejack
Jul 23 2019 19:43 UTC
@thequailman are you going to make dev/prod builds? i.e., are you bundling?
Bundlers can build different versions based on environment
(to some degree)
if (process.env.NODE_ENV === 'production') {
    prefix = 'https://prod.url/api'
} else {
    prefix = 'http://localhost:3000/api'
}
Mike McRill
@thequailman
Jul 23 2019 19:46 UTC
that was basically my plan @spacejack combined with my wrapper
spacejack
@spacejack
Jul 23 2019 19:46 UTC
And then a minifier can optimize that condition out entirely
(since you end up with if ('production' === 'production') {)
Mike McRill
@thequailman
Jul 23 2019 19:47 UTC
does mithril-query need to be updated to support 2.0?
spacejack
@spacejack
Jul 23 2019 19:47 UTC
What bundler are you using? Hopefully there's a way to use process.env in your client-side bundle.
Mike McRill
@thequailman
Jul 23 2019 19:47 UTC
webpack
spacejack
@spacejack
Jul 23 2019 19:48 UTC
Ok there should be. I'm only familiar with browserify though.
Maybe something like this?
Mike McRill
@thequailman
Jul 23 2019 19:50 UTC
        url: process.env.API_URL ?
            `${process.env.API_URL}${options.url}` :
            options.url,
spacejack
@spacejack
Jul 23 2019 19:51 UTC
I would probably try to write it out long-hand so the minifier can eliminate the dead code path
Patrik Johnson
@orbitbot
Jul 23 2019 19:51 UTC
can't remember the name off the top of my head, but there's a plugin (envify?) that attaches variables from a json file based on the NODE_ENVvariable
spacejack
@spacejack
Jul 23 2019 19:51 UTC
Though maybe it could figure that out if API_URL is replaced with ''
Yeah I've used envify for browserify
Patrik Johnson
@orbitbot
Jul 23 2019 19:52 UTC
which is nice enough in that it doesn't really require source changes after setup
Claudia Meadows
@isiahmeadows
Jul 23 2019 20:06 UTC
@orbitbot Do you happen to have a link for this? https://github.com/MithrilJS/mithril.js/pull/2482#discussion_r306408724
I'd love to include it as one more reason to do it, but it's a claim that will inevitably require verification.
Patrik Johnson
@orbitbot
Jul 23 2019 20:07 UTC
no, sorry, just some trivia I heard years ago from an ex colleague working on his thesis
could try to find the paper and check if something pops out from the references
but some stuff might be behind paywalls even then
spacejack
@spacejack
Jul 23 2019 20:09 UTC
Did they compare it against the additional time to update tests as the app codebase changes? :)
Mike McRill
@thequailman
Jul 23 2019 20:14 UTC
upfront, clear, testable specs are unicorns in my experience
is there a target date yet for 2.0.0?
Oscar
@osban
Jul 23 2019 20:20 UTC
<crickets>
Claudia Meadows
@isiahmeadows
Jul 23 2019 20:20 UTC
@orbitbot In this 2009 paper, I'm seeing a case study analysis that states a 40-90% reduction in pre-release defect density accomplished with a 15-35% increase in initial development time by teams adopting TDD who had never done it before. The developers in both the TDD and control non-TDD teams were blind to the fact they were being studied.
spacejack
@spacejack
Jul 23 2019 20:20 UTC
My intuition says... soon
Patrik Johnson
@orbitbot
Jul 23 2019 20:22 UTC
that kind of metric is kind of on topic, but can't recall what the actual stats were
testable specs are really not a thing IME either, but the point is basically that you should write tests as you go or TDD, testing after the fact is significantly slower
Patrik Johnson
@orbitbot
Jul 23 2019 20:29 UTC
arghg
there's like 70-ish references in the thesis
and a lot of them have titles like "Impact of Test-Driven Development on Productivity, Code and Tests", " Realizing Quality Improvement through Test Driven Development: [...]" and so on...
Patrik Johnson
@orbitbot
Jul 23 2019 20:39 UTC
:+1:
spacejack
@spacejack
Jul 23 2019 21:52 UTC
Holy smokes, nice overhaul of the docs @isiahmeadows
Claudia Meadows
@isiahmeadows
Jul 23 2019 21:52 UTC
Got more coming, too, but mostly in the changelog.
I want to ensure people know how to migrate from v0.2.x - a lot of people couldn't migrate to v1, but are looking to skip it altogether and go straight to v2.
Boaz Blake
@boazblake
Jul 23 2019 23:39 UTC
Hey @osban - what is the reason for the ‘object.assign’ https://gitter.im/mithriljs/mithril.js?at=5d375fd58fe53b671dc49fb3 ?
Claudia Meadows
@isiahmeadows
Jul 23 2019 23:43 UTC
So you can do post(url, {headers: {...}}) and the like.
spacejack
@spacejack
Jul 23 2019 23:43 UTC
Spread is great for overridable defaults
Claudia Meadows
@isiahmeadows
Jul 23 2019 23:46 UTC
@boazblake :arrow_up: too. I do want to point out spread properties are a newer feature, and Edge apparently doesn't support it, so you have to fall back on Object.assign({method, url: "..."}, options) instead of just using {method, url: "...", ...options}.
spacejack
@spacejack
Jul 23 2019 23:52 UTC
OT: I wonder if a small typed array 'view' (i.e., created via TypedArray#subarray()) has more or less overhead than something like the literal [1, 2, 3]
I am wondering about fast ways to work with an allocated block of data, using small pieces of it for things like vectors and other small arrays.
Oscar
@osban
Jul 23 2019 23:57 UTC
@boazblake :point_up: